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PREFACE 

This  final  report  covers  the  work  performed  under  Air  Force  Contract  F33615-80-C-5141. 
This  contract  is  sponsored  by  the  Materials  Laboratory,  Air  Force  Systems  Command, 
Wright-Patterson  Air  Force  Base,  Ohio.  It  was  administered  under  the  technical  direction  of 
Mr.  Nathan  Tupper,  ICAM  Program  Manager,  Manufacturing  Technology  Division,  through 
the  Project  Manager,  Lieut.  Douglas  Eu  banks.  The  General  Electric  project  manager  was 
Mr.  Ralph  Navarretta  of  Production  Management  &  Systems  Consulting. 

The  subcontractors  and  their  contributing  activities  were: 


Subcontractors 

Role 

Northrop 

Prepare  model  for  factory  view 

General  Dynamics 

Prepare  model  for  factory  view 

Rockwell  International 

Prepare  model  for  factory  view 

Illinois  Institute  of 
Technology  Research 
Institute  (IITRI) 

Develop  viewpoint  of  small  and  medium- 
size  aerospace  manufacturers  and  to  build 
shallow  factory  models 

SofTech 

Provide  consulting  to  the  coalition 
on  IDEF0  (function)  modeling 

D.  Appleton  Co. 

Provide  consulting  to  the  coalition 
on  IDEFt  (data)  modeling 

Pritsker  and  Associates 

Provide  consulting  to  the  coalition 
on  IDEF2  (dynamic)  modeling  and  act  as 
a  simulation  advisor 

Systems  &  Applied  Sciences 

Review  requirements  and  preliminary 
designs 

General  Electric  Corporate 
Research  and  Development 

Provide  simulation  tasks 

Control  Data  Corporation 

Provide  information  systems  requirements 

Virginia  Polytechnic 

Institute  (VPI) 

Provide  state-of-the-art  review  and 
technology  survey 

Note  that  the  number  and  date  in  the  upper  right  corner  of  each 
page  of  this  document  indicate  that  the  volume  has  been  prepared 
according  to  the  ICAM  Configuration  Management  (CM)  Life  Cycle 
Documentation  requirements  for  a  Configuration  Item  (Cl). 


NOTE: 
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Section  1 

INTRODUCTION 


1.1  OBJECTIVES 

The  objectives  of  this  project  were  to  establish,  by  the  ICAM  System  Methodology,  the 
requirements  definition,  preliminary  design,  and  detailed  design  of  an  Integrated  Planning 
System  (IPS)  to  support  the  hierarchy  of  aerospace  manufacturing,  and  to  provide  a  demon¬ 
stration  of  a  short-term  product  by  building  and  demonstrating  an  appropriately  scoped  IPS 
supporting  the  Integrated  Sheet  Metal  Center  (ISMC). 

The  importance  of  this  project  is  emphasized  by  the  fact  that  current  deficiencies  in 
higher-level  planning  systems  for  aerospace  production  are  limiting  the  implementation  of 
leading  edge  technology.  The  deficiencies  prevent  the  optimization  of: 

•  material  planning 

•  equipment  and  tool  requirements  planning 

•  capacity  planning 

•  process  plans  and  alternatives 

•  schedules 

•  shop  floor  loading 

•  order  release  systems 

This  planning  system  is  responsible  for  providing  the  plans  and  schedules  needed  to  con¬ 
vert  engineering  designs  into  manufacturing  requirements,  that  will  support  product  delivery 
to  the  customers. 

If  an  integrated  computer-aided  manufacturing  system  is  to  be  successfully  implemented 
in  the  aerospace  manufacturing  environment,  an  evolutionary  technical  baseline  for  planning 
and  control  through  an  IPS  is  imperative. 

The  early  work  on  the  project  encompassed  detailed  study  of  the  present  environment  of 
the  static  and  dynamic  planning  activities  in  aerospace  manufacturing.  This  environment  is 
represented  by  three  nodes  as  defined  by  the  ICAM  composite  view  of  Aerospace  Manufac¬ 
turing:  Plan  for  Manufacture,  make  and  Administer  Budget  and  Schedules,  and  Plan  Produc¬ 
tion.  This  detailed  study,  which  developed  prioritized  needs  for  improvements,  led  to  a  focus 
in  later  phases  of  the  project  on  the  dynamic  planning  activities,  primarily  those  associated 
with  planning  and  control  activities  from  Master  Schedule  Generation  through  Shop  Floor 
Release.  As  the  project  continued  in  preliminary  and  detailed  design,  the  planning  and  con¬ 
trol  activities  were  designed  and  further  examined. 

Study  has  shown  that  Master  Schedule  Generation,  Material  Requirements  Planning 
(MRP),  and  Capacity  Requirements  Planning  (CRP)  generally  have  been  pursued  by  several 
vendors  who  are  aggressively  starting  to  enhance  current  offerings  to  accommodate  the  needs 
of  aerospace  manufacturing.  It  therefore  became  apparent  that  the  contract  resources  should 
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be  devoted  to  those  areas  ihat  are  not  specifically  being  addressed  and  are  considered  to  be  of 
significant  value  to  aerospace  manufacturing. 

These  Planning  and  Control  areas  are: 

•  Factory  Loading 

•  Release  Production  Requirements 

•  Record  and  Provide  Production  Information 

•  Perform  Resultant  Processing 
1.2  PRINCIPAL  TASKS 

The  principal  project  tasks  were  as  follows: 

A.  Phase  I  —  Understand  the  Problem 

Phase  I,  Understand  the  Problem,  consisted  of  a  Needs  Analysis  of  the  areas  under  inves¬ 
tigation  and  then  an  assessment  of  the  potential  benefits  to  be  derived  from  addressing  these 
areas.  Since  the  scope  of  the  project  was  broad,  involving  the  study  of  more  than  100  activi¬ 
ties,  the  Needs  Analysis  was  extremely  important  in  focusing  the  effort  for  the  remainder  of 
the  project.  The  areas  of  effort  were  then  prioritized  according  to  the  potential  benefits  which 
could  be  derived  if  the  needs  of  these  functional  areas  were  satisfied. 

The  Requirements  Analysis  was  concerned  with  establishing  the  requirements  for  an  even¬ 
tual  system  and  developing  a  prioritized  list  of  improvements  that  could  address  the  principal 
benefits  to  be  realized.  To  do  this,  data  were  collected  on  existing  factories  to  characterize 
their  current  operation.  A  “factory  view”  was  then  established  for  each  of  the  factory  studies 
using  methodology  consisting  of  three  models  to  represent  three  different  views  of  a  system. 
IDEFq  was  a  functional  model  emphasizing  the  activities  performed,  IDEF,  was  the  informa¬ 
tion  model  emphasizing  the  relationships  of  data  in  the  system,  and  IDEF2  was  the  dynamic 
model  representing  the  operation  of  the  system  with  the  functions  and  the  data. 

Three  principal  aerospace  subcontractors  (Rockwell  International,  General  Dynamics,  and 
Northrop)  each  developed  a  factory  view  of  their  own  factories,  while  Illinois  Institute  of 
Technology  Research  Institute  (ITTRI)  developed  a  factory  view  of  a  small  and  a  medium¬ 
sized  subcontractor.  These  factory  views,  consisting  of  function  (IDEF0)  and  information 
(IDEFi)  models,  were  then  combined  to  establish  a  “composite  v;ew,”  which  contained  the 
functions  required  by  all  of  the  factory  views*  Finally,  based  on  the  composite  view,  “im¬ 
provement  concepts”  were  formulated  as  potential  ways  in  which  the  system  could  be  im¬ 
proved  and  the  potential  benefits  realized. 

With  the  composite  view  and  the  improvement  concepts  being  considered,  a  survey  was 
made  of  the  state  of  the  art  to  determine  what  already  existed  that  was  applicable  to  the  sys¬ 
tem  and  needed  to  address  the  improvement  concepts.  A  comparison  of  the  State-of-the-Art 
Survey  results  and  the  improvement  concepts  identified  unavailable  technology  (“technology 
voids”)  that  needed  to  be  addressed  to  satisfy  the  requirements  of  the  system. 

B.  Phase  II  —  Formulate  and  Justify  Solution 

Formulate  and  Justify  Solution  was  composed  of  two  principal  activities:  preliminary 
design  and  detailed  design.  In  the  preliminary  design,  alternate  solutions  were  formulated 
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and  evaluated  using  such  tools  as  simulation ,  consensus,  analysis,  and  discussion  by  review 
teams.  Once  a  preliminary  design  was  established,  the  detailed  design  activities  developed 
Configuration  Items  (Cl’s)  which  were  the  modules  of  the  PP&CS  system. 

C.  Phase  III  —  Construct,  Integrate,  and  Test  Subsystem 

After  a  detailed  design  was  estab'ished,  the  third  phase.  Construct,  Integrate,  and  Test 
Subsystem,  involved  implementation  of  an  IPS  prototype  system. 

The  prototype  system  consists  of  a  Factory  Loading  module  that  includes  the  following: 

•  Prepare  MRP  Inpu*  •  Define  Factory  Capacity 

•  Long-Term  Loading  (ITL)  •  Display  Capacity 

•  Long-Term  Balancing  (LIB)  •  Display  Load  vs  Capacity 

a  Short-Term  Loading  (STL)  •  Display  Detailed  Capacity  vs  Load  Profile 

•  Short-Term  Balancing  (STB)  •  Display  Load/ Balancing  Results 

•  Simulation  Capability  •  Display  Detail  Load  Schedule 

•  Process  Planning  Input 

Software  was  aiso  implemented  to  provide  the  user  with  the  following  capabilities: 

•  Define  Factory  Levels 

•  Define  Factory  Resource 

•  Display  Factory  Hierarchy 

•  Define  Machine  Type 

•  Delete  Factory  Resource 

•  Delete  Machine  Type 

•  Maintain  Shop  Calendar  Parameters 

•  Maintain  Shop  Calendar 

•  Display  Shop  Calendar 

•  Define  Move  Times 

•  Adjust  Load  Parameters 

The  software  was  implemented  on  a  VAX  11/780  using  a  VAX  II  DBMS,  DI3000  Graphics 
System  and  consists  of  a  batch  and  on-line  capability  to  perform  Factory  Loading  and  support¬ 
ing  transactions. 
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Section  2 

EXECUTIVE  SUMMARY 


This  Executive  Summary  provides  an  overview  of  the  technical  work  and  accomplishments 
of  Project  Priority  5501.  The  Executive  Summary  is  followed  by  a  detailed  discussion  (Sec* 
tion  3)  of  the  project  accomplishments,  problems,  and  solutions  to  problems. 

2.1  INTRODUCTION 

The  ultimate  goal  of  an  Integrated  Planning  and  Control  System  is  to  incorporate  the  plan¬ 
ning  and  control  activities  from  Master  Schedule  Generation  all  the  way  through  the 
manufacturing  hierarchy  to  the  shop  floor  control  activities. 

Some  of  these  activities  are  presently  incorporated  in  Material  Requirements  Planning 
(MRP)  functions  and  have  been  used  in  a  number  of  companies.  The  shop  floor  control  ac¬ 
tivities  have  been  addressed  in  the  Material  Control  Material  Management  (MCMM)  work 
under  ICAM  projects  6101  and  6103. 

Manufacturing  Control-Material  Management  (MC-MM)  is  a  computer-based  information 
system.  When  it  is  given  work  requirements,  production  instructions,  and  schedule  informa¬ 
tion,  it  can  be  used  to  control  the  execution  of  work  and  to  collect  information  relevant  to 
the  performance  of  that  work. 

MC-MM  is  a  hierarchical  control  system  designed  to  assist  production,  material  handling, 
and  stock  area  supervisors  in  optimally  applying  the  critical  resources  of  people,  equipment, 
tools,  and  material,  and  to  assist  direct  labor  personnel  in  the  performance  of  their  work.  The 
same  functions  which  are  applied  at  the  flrst-level  supervisor’s  level  or  station  are  also  applied 
at  the  cell  and  center  level.  Each  of  these  various  levels  of  control  must  plan,  load,  and 
dispatch  work  and  must  collect  feedback  to  analyze  performance  of  that  work.  This  feedback 
of  performance  along  with  historical  data  is  used  by  PP&CS  to  improve  planning  and  control 
information. 

The  Requirements  Analysis  work,  particularly  the  Needs  Analysis,  indicated  that,  at  a 
minimum,  use  of  State-of-the-Art  functionality  was  required  in: 

•  Master  Schedule  Input 

•  Material  Requirements  Planning 

•  Capacity  Requirements  Planning 

•  Release  of  “Make”  Requ.»ements  to  Factory 

However,  it  was  also  clear  that  this  functionality  alone  would  not  satisfy  the  needs  and 
that  the  control  system  must,  in  addition,  provide  organized  feedback  (resultant  processing) 
to  all  of  the  above  major  activities.  This  feedback  provides  a  means  to  base  input  assump¬ 
tions  such  as  span  time,  resource  performance  and  lot  quantity  rules  based  on  the  current  fac¬ 
tory  situation  and  its  history.  These  rules  are  currently  developed  mainly  by  experience  and 
policies. 
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The  resultant  processing  is  also  expected  to  contribute  to  improvements  in  current  MRP 
systems.  Resultant  processing  will  provide  accurate  and  timely  information  relative  to 
resource  performance,  work-in-process,  and  inventory  status.  This  is  expected  to  significantly 
improve  the  accuracy  of  the  aforementioned  functions.  Ultimately,  this  information  can  be 
utilized  by  the  Plan  for  Manufacturing  and  Plan  Production  functions. 

The  key  to  effective  utilization  and  development  of  resultant  processing  is  the  availability 
of  this  timely  and  acetate  resource  performance  information  from  the  MCMM  system  at  all 
levels  of  the  control  nierarchy. 

Finally,  it  was  accessary  to  integrate  the  process  planning  activities  with  the  planning  and 
control  functions.  The  process  planning  information  was  used  to  develop  the  capacity  re¬ 
quirements  planning  (CRP  )  profile  of  shop  resources.  This  integration  consisted  of  the  com¬ 
munication  of  process  planning  information  from  the  Plan  Production  activity  and  the  organi¬ 
zation  and  integration  of  this  information  so  that  production  requirements  cam  be  released  to 
the  factory  through  the  Release  Production  Requirements  function. 

A  comparison  of  PP&CS  capacity  requirements  planning  was  compared  to  commercially 
available  CRP  systems.  PP&CS  was  found  to  be  more  advanced  according  to  APICS  definition 
due  to  the  fact  that  PP&CS  loaded  at  a  lower  level  of  resource,  thus  providing  an  improved 
measure  of  accuracy. 

2.1.1  Overview  of  PP&CS 

Thus,  at  the  Production  Planning  and  Control  (PP&CS)  level,  the  anticipated  structure  of 
the  integrated  planning  and  control  hierarchy  illustrated  in  Figure  2-1  includes: 

•  Master  Schedule  Input 

•  Material  Requirements  Planning 

•  Sequence  Loading  &  Balancing 

•  Integration  of  Process  Planning 

•  Release  of  “Make”  Requirements 

•  Record  &  Provide  Production  Information 

»  Factory  Feedback 

•  Resultant  Processing 

These  activities  produce  production  requirements  for  the  factory  hierarchical  control  sys.- 
tem. 

The  benefits  expected  to  be  achieved  from  a  Production  Planning  and  Control  System  are: 

•  Reduced  Direct  and  Indirect  Labor 

—  Through  better  application  of  labor 

•  Reduced  Cycle  Times 

—  By  identifing  and  resolving  bottle  necks 

•  Reduced  Inventory 

—  By  better  control  of  job  starts  on  the  shop  floor  along  with  tracking  of  completions. 
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•  Improved  resource  utilization 

—  By  providing  a  balanced  load  according  to  a  prioritized  schedule 

•  Increased  factory  Throughput 

—  By  scheduling  and  loading  the  factory  based  on  historical  and  current  data  which  will 
allow  opportunity  to  reduce  cycles. 

•  Ability  to  analyze  performance  to  plan 

—  By  providing  a  closed  loop  feedback  system  between  PP&CS  and  the  shop  floor 

•  Reduced  management  overhead 

—  By  iden tiling  problems  early  to  decrease  expediting 
—  Exception  reporting  vs.  mass  print  outs 

The  modules  of  PP&CS  which  were  constructed  and  implemented  for  demonstration 
under  Project  Priority  5501  are: 

•  Sequence  Loading  and  Balancing 

•  Release  Production  Requirements 

•  Record  and  Provide  Information 

•  Resultant  Processing 
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Figure  2-1.  Production  Planning  and  Control  Concept 
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The  modules  such  as  master  scheduling,  material  requirements  planning  (MRP),  process 
planning,  and  the  shop  floor  control  system  can  oe  implemented  via  existing  commercially 
available  systems. 

Following  is  a  brief  description  of  these  activities: 

A.  Master  Schedule  Input 

Master  scheduling  is  basically  a  work  planning  assignment.  It  is  the  task  of  committing 
*  factory  production  resources  —  manpower,  machines,  and  materials  —  to  filling  actual  or  an¬ 

ticipated  customer  orders.  In  brief,  the  question  that  must  be  answered  is:  “How  can  avail¬ 
able  factory  capacity  be  best  utilized  to  make  the  required  number  and  variety  of  shippable 
end  items?”  The  output  from  master  scheduling  is  customer  products  or  major  components 
with  associated  quantities  and  completion  dates.  Inputs  come  from  all  facets  of  the  business: 
Marketing,  Engineering,  Manufacturing  Engineering,  and  Purchasing.  This  activity 
transforms  management’s  operating  strategies  for  each  function  of  the  business  into  unified 
operating  goals. 

During  master  scheduling,  specific  quantities  and  dates  are  assigned  that  will  trigger  the 
entire  production  process.  The  Master  Schedule  authorizes  both  factory  and  office  to  spend 
money  and  sets  production  performance  standards  throughout  the  organization.  Changes,  al¬ 
terations,  failures  and  even  successes  should  be  carefully  analyzed.  The  master  schedule  is 
manufacturing’s  common  goal  with  the  other  functional  operations  within  the  business. 

The  PP&CS  prototype  utilizes  schedule  input  for  shippable  end  items  and  quantities  from 
an  existing  higher-level  system. 

B.  Material  Requirements  Planning 

Material  Requirements  Planning  is  the  process  of  converting  end  items  specified  on  the 
master  schedule  into  lower-level  purchased  and  manufactured  subassemblies  and  components. 
These  requirements  are  netted  against  the  inventory  position  to  produce  the  net  requirements 
to  be  purchased  or  placed  on  the  factory. 

The  process  is  accomplished  through  a  bill  of  material  level-by-level  explosion,  which  uti¬ 
lizes  the  manufacturing  indentured  parts  lists.  Information  is  contained  within  the  manufac¬ 
turing  indentured  parts  lists  to  indicate  the  applicability  of  specific  subassemblies  and  com¬ 
ponents  to  the  product  being  dealt  with.  Each  component  at  each  level  is  set  back,  according 
to  predetermined  span  times,  to  produce  estimated  availability  requirement  dates  for  the 
dependent  lower-level  suoassemblies  and  components.  The  net  requirements  are  summarized 
according  to  predetermined  lot  sizing  policies.  The  results  are  firm  orders  to  be  placed  on 
purchasing  or  the  factory  (production  requirements).  The  production  requirements  are  sub¬ 
jected  to  broad  parameters  of  factory  capabilities  to  determine  the  probability  of  being  able  to 
meet  the  specified  schedule. 

Records  are  kept  of  the  gross  requirements  generated.  Tney  are  identified  (or  pegged)  to 
the  next  higher  assembly  or  end  product  usage  by  next  assembly  part  number  and  order 
number.  The  requirements  records  are  used  for  supporting  subsystems  to  allocate  available 
inventory  and  produce  lot  sized  orders  on  the  factory. 

An  important  advantage  of  the  Material  Requirements  Planning  system  is  the  ability  to 
track  products.  This  tracking  process  determines  when  and  where  in  the  bill  of  materials 
changes  should  be  incorporated  into  the  product. 

The  PP&CS  project  uses  an  existing  MRP  system  in  its  prototype  implementation. 
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C.  Factory  Loading  and  Balancing 

After  the  production  requirements  are  created,  validation  of  the  probability  of  achieving 
the  manufacture  of  those  requirements  within  very  broad  parameters  of  factory  capabilities  is 
performed.  Forward  or  backward  loading  on  the  factory  is  performed  within  the  defined  limits 
of  available  capacity.  The  production  requirements  are  compared  to  the  production  instruc¬ 
tions  (process  routing)  to  explode  labor.  Two  types  of  loading  and  balancing  are  available. 
The  first  type  is  for  an  extended  horizon  (to  be  selected  by  the  user).  This  function  analyzes 
and  loads  the  factory  at  the  summary  level.  The  load  profile  segment  selected  is  of  a  duration 
long  enough  to  identify  capacity  problems  in  a  range  of  capacity  versus  load  over  time  to  at¬ 
tempt  to  solve  the  capacity  problem  through  leveling  of  the  load. 

Assuming  a  successful  summary  load,  a  shorter  horizon  may  be  selected  for  detail  opera¬ 
tion  loading  at  the  process  level.  This  is  accomplished  in  a  similar  manner.  Summarized 
analysis  is  performed  to  detect  the  points  at  which  production  rate  changes  impact  capacity 
availability.  Adjustments  are  made  to  slack  time,  flow  time  and  priorities.  Reloading  is  ac¬ 
complished  to  develop  minimum  capacity  requirements  to  achieve  the  load.  All  conditions, 
assumptions  and  unresolved  problems  are  displayed. 

The  production  requirements  are  used  to  plan  the  required  capacity  to  achieve  the  load 
placed  on  the  factory.  Production  instructions  (process  routings),  capacity  identification  and 
availability  are  obtained  through  external  interfacing  systems.  Span  times,  alternate 
processes,  parallel  processing,  experience,  capacity  limitations  and  resource  effectiveness  are 
considered  in  establishing  the  planned  load. 

The  developed  load  is  the  anticipated  activity  expressed  in  hours  for  a  machine,  depart¬ 
ment  or  facility.  The  developed  load  is  normally  constructed  by  multiplying  the  lot  quantities 
to  be  built  by  the  run  time  per  piece  and  then  adding  the  seiup  time  for  the  lot. 

The  total  work  load,  composed  of  released  and  unreleased  load,  is  segregated  into  time 
periods  to  create  a  capacity  versus  load  profile  to  illustrate  both  underload  and  overload  situa¬ 
tions.  Once  the  current  load  situation  is  known,  the  option  is  available  to  forward  or  back¬ 
ward  load  and  develop  alternative  strategies  so  that  the  best  solution  can  be  chosen  consider¬ 
ing  the  information  currently  available.  The  developed  alternatives  such  as  redeployment  of 
resources,  additional  shifts,  additional  facilities,  etc.  are  evaluated  taking  into  account  manage¬ 
ment  directives,  schedule  restrictions  and  resource  restrictions  to  arrive  at  the  best  alterna¬ 
tives  for  the  particular  problem. 

Once  a  particular  solution  has  been  reached,  a  “plan  request”  can  be  generated  to  initiate 
the  plan  of  action  that  has  been  chosen.  The  plan  of  action  may  simply  be  a  matter  of  balanc¬ 
ing  the  load  within  the  schedule  constraints  that  exist,  increasing  capacity  to  meet  schedule 
demands,  or  rescheduling  due  to  the  constraints  of  the  machine,  department  or  facility  in 
question. 

The  actual  time  horizons  of  the  planned  load  vary  depending  on  such  factors  as  the 
characteristics  of  the  material  flow,  the  criticality  of  the  manufacturing  processes  employed, 
and  the  rate  at  which  resource  assignments  can  be  changed. 

The  PP&CS  system  is  designed  to  access  a  system  like  Material  Control  Material  Manage¬ 
ment  (MCMM)  directly  to  obtain  status  of  current  load  and  completions. 

D.  Release  of  “Make”  Requirements  to  Factory 

Once  the  load  has  been  developed  for  a  particular  item  to  be  manufactured,  that  informa¬ 
tion,  together  with  the  process  plan  and  required  schedules,  is  released  to  the  factory.  At  this 
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point,  total  load,  previously  released  and  new,  has  been  taken  into  consideration.  Material  is 
either  available  or  scheduled  to  meet  required  due  dates  and  capacity  has  been  developed  to 
meet  necessary  manufacturing  requirements.  As  additional  load  is  required,  the  information 
released  to  the  factory  is  updated  so  that  the  total  current  load  is  always  available. 

£.  Integration  of  Process  Planning 

Process  planning  for  parts  and  assemblies  must  be  carried  out  to  specify,  in  careful  detail, 
the  processes  required  and  their  sequence.  These  processes  and  sequence  are  developed  to 
achieve  minimum  cost  and  to  meet  the  exacting  requirements  of  the  product  design 
specifications.  The  application  of  resources  to  accomplish  the  making  of  parts  is  complex. 
The  complexity  is  due  to  different  sizes  and  shapes  of  parts,  quality  of  finish  required,  accura¬ 
cy  demands,  and  differences  in  output  rate  required.  The  information  contained  on  the  pro¬ 
cess  master  file  is  used  as  input  to  the  sequence  loading  and  balancing  module,  which  con¬ 
structs  ioad  hour  profiles  versus  hours  of  capacity  for  factory  resources. 

The  primary  process  pfenning  information  required  to  support  the  PP&CS  Factory  Loading 
function  is  as  follows: 

•  Resource  ID 

•  Part  number 

•  Operation  sequence  number 

•  Setup  hours 

•  Standard  hours 

•  Tooling 

•  Materia! 

F.  Record  acd  Provide  Production  Information 

This  function  is  primarily  responsible  for  maintaining  factory  environment  information 
and  is  also  intended  to  maintain  both  planned  and  actual  performance  information.  Factory 
environment  information,  e.g.,  machines,  machine  types,  shop  calendar  information,  factory 
organization,  etc.  is  obtained  from  the  organization  responsible  for  the  factory  configuration. 
Planned  information  is  obtained  through  the  planning  functions.  Actual  production  informa¬ 
tion  is  obtained  from  resultant  processing. 

All  information  is  validated  for  correct  format  and  content.  If  valid,  the  information  is 
stored  and  retrieved  upon  request.  Experience  information  is  reported  about  scrap  and 
shrinkage,  span  times,  yield  and  historical  performance.  Production  requirements  information 
is  provided  and  status  information  is  reported. 

The  feedback  from  the  factory  is  processed,  validated  and  stored.  Performance  informa¬ 
tion  and  recommendations  are  developed  and  fed  to  the  factory  and  to  the  higher-level  plan¬ 
ning  and  scheduling  functions. 

G.  Resultant  Processing 

Resultant  processing  comprises  the  analysis,  conditioning,  storing  and  use  of  feedback  in¬ 
formation  obtained  on  a  timely  basis  through  the  control  hierarchy.  It  is  used  to  predict  fu¬ 
ture  performance  based  on  trends  and  observations  obtained  from  prior  experience. 

The  information  to  be  used  and  analyzed,  includes  standard  hours  from  process  plans, 
planned  hours  from  production  requirements,  queue  size/time  relationships  and  liquidated 
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hours  from  the  factory  feedbtck  system,  yield  experience  from  scrap  analysis,  and  present 
load  status  from  the  factory  control  system. 

The  information  is  analyzed  for  inconsistencies  and  extremes.  Data  within  predefined  lim¬ 
its  are  maintained  as  history.  The  new  information  is  compared  to  historical  performance. 
Any  new  trends  detected  will  be  used  in  the  development  of  more  realistic  production  re¬ 
quirement  schedules.  Predictions  are  made  about  potential  progress  in  achieving  current  load 
based  on  prior  performance. 

2.1.2  Production  Planning  and  Control  (PP&CS)  Users 
The  PP&CS  user  types  are  as  follows: 

Manufacturing  Analysts 

•  Database  Administrator 

•  System  Analyst 
Manufacturing  User 

•  Shop  Floor  Control 

•  Manufacturing  Planner 

•  Production  Planner 

•  Resource  Planner 

•  Tool  Planners 

•  Production  Schedulers 
Management  User 

•  Shop  Management 

•  Inventory  Managers 

•  Strategic  Planners 

•  Company  Management 

2.1.3  Summary 

The  above  discussion  of  PP&CS  functional  characteristics  a-e  expected  to  perform  long 
range  planning  in  a  batch  mode  and  dynamic  and  short  range  planning  tasks  on-line,  using 
exception-type  parameters  and  reporting. 

2.2  TECHNICAL  WORK  AND  ACCOMPLISHMENTS 

The  following  is  a  synopsis  of  technical  work  accomplishment  during  the  life  of  Project 
Priority  5501. 

2.2.1  Contribution  of  IPS  Subcontractors 

Due  to  the  large  scope  and  size  of  Phase  I,  Understand  the  Problem,  it  was  decided  to  ap¬ 
portion  specific  tasks  to  aerospace  companies  and  to  support  those  efforts  with  consultants  to 
ensure  consistency  in  methodology  for  functional  and  information  modeling  of  the  particular 
tasks.  The  subcontractors  and  their  contributing  activities  are  referenced  in  the  Preface  of 
this  report. 
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2.2.2  Development  of  Master  Plan  and  Schedule 

A  master  plan  and  schedule  was  developed  to  define  the  project  objectives,  tasks,  sub- 
stasks,  schedules,  budgets,  materials  and  method,  facilities,  personnel  and  deliverables  re¬ 
quired.  A  Systems  Environment  Document  (SED)  was  prepared  to  provide  guidance  to  the 
IPS  coalition  team  before  the  modeling  activity  commenced. 

2.2.3  Data  Collection  Experiment 

A  data  collection  experiment  to  evaluate  methodology  proposed  by  the  Air  Force  was  con¬ 
ducted  using  subcontractor  and  Genetai  Electric  personnel.  This  process  used  a  coding  system 
for  all  inputs  and  outputs  during  the  data  collection  process.  The  objective  was  to  sort  by 
code  to  identify  like  attributes  and  entities  that  would  be  helpful  in  preparation  of  a  system 
design.  Results  of  this  experiment  were  inconclusive. 

2.2.4  Needs  Analysis  Identification 

A  Needs  Analysis  was  performed  by  each  of  the  aerospace  subcontractors  and  General 
Electric  for  the  following  major  subtasks  of  Phase  I: 

Task  1  Manufacturing  Planning  Subtask  (MPS)  -  Performed  by  Rockwell  International 

Task  2  Process  Planning  Subtask  (PPS)  —  Performed  by  General  Dynamics 

Task  3  Plan  for  Manufacturing  Subtask  (PMS)  —  Performed  by  Northrop  Corporation 

A  Needs  Analysis  Document  (NAD)  was  developed  as  a  result  of  this  effort. 

2.2.5  “As-Is”  Factory  and  Dynamic  Models 

Factory  models  were  developed  using  IDEF0  methodology  for  each  of  the  major  subtasks 
of  Phase  I.  In  addition,  dynamic  models  were  constructed  of  selected  areas  of  the  “As-Is” 
factory  function  models  to  provide  dynamics  data  through  simulation  for  use  in  constructing 
improvement  concepts. 

2.2.6  “As-Is"  Composite  Factory  Models 

Each  subcontractor  that  had  primary  responsibility  for  the  function  model  of  a  subtask  in 
Phase  I  prepared  a  shallow  model  of  the  other  subtasks  on  Phase  I  for  its  factory.  Through 
analysis  and  consensus,  composite  factory  models  were  constructed  for  each  subtask  in 
Phase  I.  The  methodology  was  supported  by  modeling  consultants  during  the  “As-Is”  com¬ 
posite  factory  modeling  process. 

2.2.7  “As-Is"  Information  Models 

Information  models  were  constructed  for  each  subtask  in  Phase  I  by  the  responsible  task 
leader.  The  models  consisted  of  five  phases  of  detail,  as  follows: 

Phase  Ze.o  —  Writeup  of  the  “Strategic  Objective” 

Phase  One  —  Definitions  of  Entity  Classes 

Phase  Two  —  Development  of  Entity  Class  Diagrams 

Phase  Three  —  Define  Key  Attribute  Classes 
—  Develop  Attribute  Diagrams 
—  Prepare  Attribute  Class  Migration  Index 


.  ■.  ovw-v-r  w.*?  o  tV.  vv 


FTR550150000U 
30  November  1984 


Phase  Four  —  Define  Non-Key  Attribute  Classes 
—  Prepare  Function  View  Diagrams 
-  Prepare  Compiete  Model 

2.2.8  Development  of  Improvement  Concepts 

Improvement  Concepts  were  developed  as  a  result  of  prioritizing  the  Needs  Analysis  to 
determine  a  concept  for  improvement  and  eventual  system  design.  Function  models  were 
prepared  for  each  potential  improvement  concept.  A  Systems  Requirement  Document  (SRD) 
was  prepared  to  aid  in  the  development  of  the  state-of-the-art  survey. 

2.2.9  State-of-the-Art  Survey 

A  questionnaire  was  developed  as  a  result  of  the  formulation  of  improvement  concepts 
and  was  sent  to  various  software  houses  to  determine  whether  the  functionality  could  be 
satisfied  with  commercially  available  software.  After  analyzing  the  State-of-the-Art  Survey, 
the  technology  voids  for  IPS  design  were  identified.  A  State-of-the-Art  document  was 
prepared  as  a  result  of  this  activity. 

2.2.10  Development  of  IPS  Preliminary  Design 

A  conceptual  design  was  developed  in  the  form  of  IDEF0  models  with  appropriate  text  and 
glossary,  using  the  improvement  concepts  and  technology  voids  as  input  to  this  task. 

2.2.11  Preliminary  Design  Comparison  to  MRPII  Concepts 

An  analysis  of  industrial  users  cf  MRP  systems  was  developed  and  conducted  to  deter¬ 
mine  system  benefits.  Vendor-supplied  MRP  packages  were  evaluated  against  the  functionali¬ 
ty  specified  in  the  IPS  preliminary  design.  During  this  process,  a  Capacity  Requirements 
Planning  (CRP)  state-of-the-art  analysis  was  completed.  Using  functional  requirements  for  a 
CRP  package  a  software  questionnaire  was  developed,  and  the  responses  served  as  the  basis 
of  this  analysis. 

2.2.12  Development  of  an  IPS  “To-Be”  System  Specification  (SS)  for  Production  Planning 
and  Control  (PP&CS) 

The  functional  requirements  were  prioritized  based  on  estimated  benefits.  The  technology 
voids  for  each  requirement  were  ranked  according  to  the  test  opportunity  to  develop  the 
needed  technology.  The  specification  included  the  following  requirements: 

•  Experience  and  Capability  Information 

•  Lot  Sizing  Technique 

•  Level  Loading 

•  Effective  Control  of  Capacity  and  Resources 

•  Control  Thread  Requirements 

The  system  specification  document  included  the  definition  of  the  information  require¬ 
ments  needed  to  support  the  system  requirements  identified  above. 

2.2.13  Development  of  a  System  Design  Specification  (SDS)  for  the  “To-Be”  PP&CS  Pro¬ 
totype 

The  SDS  defined  the  configuration  items  (functionality)  that  needed  to  be  developed  to 
satisfy  the  system  requirements.  This  document  also  included  the  data  characteristics,  data 
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requirements,  data  collection  and  transfer  procedures,  inputs,  outputs,  interfaces,  design  and 
construction  standards,  human  engineering  and  personnel  training  and  quality  assurance  pro¬ 
visions. 

2.2.14  Development  of  Computer  Development  Specifications  (DS)  for  the  “To-Be” 

PP&CS 

Development  Specifications  (DS)  were  developed  for  each  configuration  item  defined  in 
the  System  Design  Specification.  The  Development  Specifications  detailed  the  system  capaci¬ 
ties,  interface  requirements,  functional  requirements,  inputs,  processing  details,  outputs  and 
quality  assurance  provisions. 

2.2.15  Software  Design  Approach  and  Implementation  Strategy 

This  activity  developed  software  design  procedures,  software  design  approach,  detail 
design  assumptions  and  system  implementation  strategy  for  PP&CS. 

2.2.16  Development  of  Heuristic  Load  Balancing  Techniques 

A  detail  manual  was  constructed  to  procedurally  describe  the  algorithms  and  heuristic 
rules  that  would  be  utilized  in  the  software  for  the  loading  and  balancing  of  jobs  on  resources. 

2.2.17  Resultant  Processing  Approach 

A  detailed  approach  identifying  algorithms  and  statistical  techniques  to  collect  feedback 
and  process  the  results  of  the  data  was  accomplished.  The  design  for  inputs  and  outputs  for 
the  system  were  identified,  and  the  ability  for  trend  diagrams  to  be  graphically  displayed  was 
described. 

2.2.18  Quality  Assurance  Plan  (QAP) 

A  quality  assurance  plan  for  the  software  development  effort  was  produced.  This  docu¬ 
ment  addressed  the  issues  of  development  tools,  techniques  and  methodologies,  computer 
program  design,  documentation  standards,  computer  program  library  controls,  reviews  and 
audits,  configuration  management,  testing  and  corrective  action  procedure. 

2.2.19  PP&CS  Data  Base  Approach 

A  data  base  schema  was  developed  to  support  the  PP&CS  system.  The  PP&CS  data  base 
was  constructed  using  VAX  11  DBMS,  a  CODASYL-compliant  data  base  management  sys¬ 
tem.  The  schema  detailed  the  record  types,  record  relationships,  information  contained  within 
record  types,  storage  areas,  physical  placement  of  records,  and  set  characteristics  including 
insertion  nodes,  record  retention  and  logical  ordering. 
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Section  3 

PROJECT  ACCOMPLISHMENTS 


Project  Accomplishments  by  Work  Breakdown  Structure 

The  work  breakdown  structure  (Figure  3-1)  for  Project  Priority  5501  consisted  of  seven 
tasks  and  26  subtasks.  The  project  was  broken  down  as  follows: 

Task  1  Program  Planning 

Subtask  1  —  Develop  Master  Plan  and  Schedule 

Task  2  Manufacturing  Planning  (MPS) 

Subtask  1  —  Develop  and  Understand  the  MPS  Problem 

Subtask  2  —  Analyze  Needs  for  MPS 

Subtask  3  —  Build  “As-Is”  Factory  View 

Subtask  4  —  Build  “As-Is”  Composite  MPS  Factory  View 

Subtask  5  —  Formulate  Improvement  Concepts  for  MPS 

Subtask  6  —  Review  State-of-the-Art  for  MPS 

Task  3  Process  Planning  (PPS) 

Subtask  1  —  Develop  and  Understand  the  PPS  Problem 
Subtask  2  —  Analyze  Needs  for  PPS 
Subtask  3  —  Build  “As-Is”  PPS  Factory  View 
Subtask  4  —  Build  “As-Is”  Composite  PPS  Factory  View 
Subtask  5  —  Formulate  Improvement  Concepts  for  PPS 
Subtask  6  —  Review  State-of-the-Art  for  PPS 

Task  4  Plan  for  Manufacture  (PMS) 

Subtask  1  —  Develop  and  Understand  the  PMS  Problem 
Subtask  2  —  Analyze  Needs  for  PMS 
Subtask  3  —  Build  “As-Is”  PMS  Factory  View 
Subtask  4  —  Build  “As-Is”  Composite  PMS  Factory  View 
Subtask  5  —  Formulate  Improvement  Concepts  for  PMS 
Subtask  6  —  Review  State-of-the-Art  for  PMS 

Task  5  Design  IPS 

Subtask  1  —  Develop  “Formulate  and  Justify  Solution”  Subplan 
Subtask  2  —  Establish  Preliminary  Design 
Subtask  3  —  Establish  Detailed  Design 

Task  6  Construct,  Integrate  and  Test  IPS  Subsystem. 

Subtask  1  —  Develop  “Construct  Integrate  and  Test”  Subplan 
Subtask  2  —  Construct,  Code  and  Verify  IPS  Subsystem  Prototype 
Subtask  3  —  Integrate,  Test  and  Validate  IPS  Subsystem  Prototype 
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Sublask  4  —  Implement  and  Maintain  IPS  Subsystem  Prototype 


Task  7  Project  Management  arid  Data 

3.1  TASK  1,  SUBTASK  1:  DEVELOP  MASTER  FLAN  AND  SCHEDULE 

3.1.1  Scope 
Accomplishments 

A  review  of  the  draft  scope  was  completed.  A  revised  scope  was  published  in  Project 
Priority  5501’s  first  interim  report. 

The  directly  supported  nodes  were  taken  from  the  integration  document  supplied  with  the 
Project  Priority  5501  RFP. 

An  analysis  was  performed  using  the  Manufacturing  Architecture  MFGo  model  and 
specific  exceptions  were  noted  and  documented  in  the  first  interim  report. 

A  master  plan  and  schedule  was  developed  and  defined  the  project  objectives,  tasks,  sub¬ 
tasks,  schedules,  budgets,  materials  and  method,  facilities,  personnel  and  deliverables  re¬ 
quired. 

3.2  TASK  2,  SUBTASK  1:  DEVELOP  AND  UNDERSTAND  THE  MANUFACTURING 
PLANNING  SUBTASK  (MPS)  PROBLEM 

3.2.1  MPS  Requirements  Definition 
Accomplishments 

A  detailed  plan  was  developed  with  Rockwell  International  and  General  Electric  to  per¬ 
form  requirements  definition.  Needs  Analysis,  and  state-of-the-art  assessment  of  the  “As-Is” 
MPS  arena  with  emphasis  on  the  formulation  of  improvement  concepts  for  this  task.  The 
plan  included  training,  data  collection  techniques,  model  building,  validation  process,  analysis 
and  state-of-the-art  review. 

The  scope  of  the  MPS  study  effort  was  developed  in  the  form  of  an  IDEFo  kit  published 
in  the  first  interim  report  and  was  used  by  Rockwell  International  and  General  Electric  as  the 
guide  for  understanding  the  MPS  problem. 

3.2.2  Task  2,  Subtask  2:  Analyze  Needs  for  MPS 
3.2.11  MPS  Needs  Analysis 

Accomplishments 

A  Needs  Analysis  was  completed  for  the  MPS  task.  An  understanding  of  the  functional 
requirements,  computer  application  strategies,  interface  requirements  and  problems  was  de¬ 
veloped.  Needs  were  prioritized  based  on  established  criteria  such  as  cost  drivers,  potential 
benefits,  and  human  factors.  The  primary  needs  identified  in  the  MPS  arena  were  as  follows: 

•  Automated  Master  Schedule  and  First  Article  Schedule 

•  Automated  Assembly  Build  Schedule 

•  Ability  to  Establish  Optimum  Program  and  Production  Lot  Sizes 
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•  Automated  Center  Level  Schedules 

•  Automated  Data  Collection  for  Line-of- Balance  Statusing 

•  Provide  Computer-Assisted  Cost  Package  Estimation 

•  Computer-Assisted  Optimization  of  Work  Authorization  Release  Time 

•  Machine/Tool  Load  Schedules 

Satisfying  the  above  needs  indicated  a  potential  savings  for  a  major  airplane  program  to  be 
in  excess  of  S45  million. 

The  needs  for  MPS  were  prioritized  and  used  in  the  development  of  improvement  concept 
design  for  IPS.  The  detailed  Needs  Analysis  for  MPS  was  documented  in  the  second  IPS  in¬ 
terim  report  (ITR550150002U). 

3.2.3  Task  2,  Subtask  3:  Build  “As-Is”  MPS  Factory  View 

3.13.1  MPS  Function  and  Information  Modeling 
Accomplishments 

An  IDEF0  function  model  and  an  IDEFt  information  model  were  constructed  based  on 
the  priorities  established  in  the  Needs  Analysis.  It  was  determined  that  the  process  of 
developing  coordinating  schedules  really  encompassed  the  major  needs  identified  for  MPS. 

Based  on  this  decision,  the  function  and  information  modeling  effort  concentrated  on  the 
Develop  Coordinating  Schedules  arena.  The  top  view  of  the  function  model  is  referenced  in 
Figure  3-2,  labeled  RH1,  and  Figure  3-3,  labeled  RH2.  The  information  model  overview  is 
referenced  in  Figure  3-4,  labeled  RH006;  and  Figure  3-5,  labeled  RH008. 

The  complete  IDEF0  function  model  kit  number  AIM550152100  and  the  IDEFt  informa¬ 
tion  model  kit  number  AIM5501 52200  are  available  in  the  ICAM  library. 

The  process  of  MPS  factory  modeling  added  25  bottom-  level  nodes  to  the  Manufacturing 
Architecture  MfGo-  These  added  nodes  were  a  result  of  a  further  breakdown  of  activities  in 
the  Develop  Coordinating  Schedules  arena. 

3.2.4  Task  2,  Subtask  4:  Build  “As-is”  Composite  MPS  Factory  View 

3.14.1  MPS  Composite  Factory  Vi*:? 

Accomplishments 

An  IDEF0  and  IDEFj  model  of  MPS  was  completed. 

Using  the  completed  Rockwell  International  factory  view  of  MPS,  the  balance  of  the  coali¬ 
tion  provided  their  DEF0  and  IDEF[  data  and  models  of  MPS.  This  effort  provided  a  formal 
review  and  consensus  that  led  to  concurrence  of  the  coalition  on  the  final  composite  view 
models  of  MPS. 

In  order  to  assure  that  results  were  achieved  in  the  three  major  areas,  MPS,  PPS  and  MPS 
the  subcontractors  expertize  was  utilized  in  a  manner  which  minimized  their  detail  modelling 
efforts.  The  technique  allowed  each  of  the  subcontractors  to  concentrate  on  a  specific  area  and 
still  provide  significant  input  to  the  other  areas. 
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Figure  3-3.  Develop  Coordinating  Schedules 
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Figure  3*4.  Kit  Overview 


Figure  3-5.  Kit  Overview 
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Figure  3-6  represents  the  technical  IDEF0  and  IDEFi  modeling  approach  used  by  General 
Electric  and  its  coalition  consisted  of  the  following  steps: 

•  Three  independent  IDEF0  shallow  factory  view  models  of  integrated  planning  were  built 
by  the  subsystem  principal  subcontractors. 

•  A  composite  model  was  derived  from  the  shallow  factory  views. 

•  Additional  factory  view  IDEF0  modeling  was  provided,  detailing  extensions  to  the  com¬ 
posite  “top,”  with  each  subsystem  principal  subcontractor  concentrating  on  an  area  of 
planning  expertise  (Manufacturing  Planning,  Process  Planning,  or  Plan  for  Manufac¬ 
ture). 

•  Each  subsystem  principal  subcontractor  modeled  less  extensively  in  IDEF<>  one  other 
area  as  directed  by  General  Electric. 

•  Each  subsystem  principal  subcontractor  produced  graphical  IDEF,  models  corresponding 
to  the  data  associated  with  the  functions  that  they  modeled  in  IDEF0. 

•  A  baseline  composite  view  IDEFo  model  was  developed  from  the  factory  view  IDEFo 
models. 

•  A  baseline  composite  view  IDEFi  model  was  developed  from  the  factory  view  IDEF) 
models,  with  subsequent  detailed  documentation  of  attribute  classes  carried  out  by  coali¬ 
tion  members  during  the  composite  modeling  task. 

•  Baseline  models  were  formally  reviewed  by  coalition  members  and  the  Air  Force  PMO, 
leading  to  concurrence  on  final  composite  view  IDEF0  and  IDEF]  models. 

The  modeling  efforts  were  carried  out  by  “chief  author”  teams,  as  illustrated  by  Fig¬ 
ure  3-7.  The  team  consisted  of  a  chief  author  experienced  in  IEDF0  and/or  IDEF,  along  with 
one  or  more  additional  persons  with  IDEF  experience,  depending  on  the  model  being  built. 

Under  this  approach,  the  principal  aerospace  subcontractor  and  IDEF  consultant  formed  two 
modeling  teams:  one  IDEF0  team  and  one  IDEFt  team.  The  two  teams  were  led  by  a  chief 
author  who  was  responsible  for  understanding  both  models  produced  under  his  or  her  direc¬ 
tion,  and  their  interrelationships.  General  Electric,  with  this  approach,  facilitated  the  develop¬ 
ment  of  the  IDEF0  and  IDEF1  models  without  sacrificing  the  conceptual  independence  of  the 
models.  The  chief  authors  utilized  the  IDEF0  models  for  guidance  in  developing  IDEF, 
models,  and  called  upon  their  familiarity  with  both  models  in  subsequently  correlating  the 
IDEFo  and  IDEF,  models  to  resolve  terminology  differences. 

3.2.5  Task  2,  Subtask  5:  Formulate  Improvement  Concepts  for  MPS 

3.2.5. 1  MPS  Improvement  Concepts 

Accomplishments  < 

The  improvement  concepts  prioritized  for  MPS  were  developed  from  a  major  category  list 
of  15  technologies  that  were  compiled  from  the  Needs  Analysis.  The  result  of  this  analysis 
indicated  that  the  most  important  improvements  in  MPS  technology  were: 

•  Scheduling  Capabilities 

•  Resource  Allocation  and  Control 

The  composite  “As-Is”  factory  model  for  MPS  was  used  to  determine  improvement  con¬ 
cepts  for  further  study  and  evaluation.  The  process  by  which  the  improvement  concepts  were 
developed  for  MPS  was  as  follows: 
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Figure  3-6.  IDEF0  Modeling 
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IDEF. 


Figure  3-7.  Chief  Author  Teem 

•  Identify  performance  measures  for  MPS  via  Needs  Analysis,  State-of-the-Art  Survey, 
and  the  Manufacturing  composite  view  architecture. 

•  Develop  an  improvement  concept  and  discuss  in  scenario  form  the  details  and  support 
the  activity  with  an  IDEFq  function  model. 

•  Compare  the  improvement  concepts  identified  with  information  received  from  the  state- 
of-the-art  questionnaire  results. 

An  example  of  improving  scheduling  capabilities  and  resource  allocation  and  control  is 
depicted  in  Figures  3-8,  3-9,  and  3-10,  referenced  IC13.  IC14,  and  IC15. 

The  total  development  details  related  to  MPS  improvement  concepts  are  included  in  the 
15  major  technologies  contained  in  the  third  IPS  interim  report  (ITR550150003U). 

3.2.6  Task  2,  Subtask  6:  Review  State  of  the  Art  for  MPS 

3.2,6. 1  MPS  State-of-the-Art  Surrey 

Accomplishments 

The  State-of-the-Art  Survey  was  compared  to  the  improvement  concepts  and  resulted  in 
the  identification  of  requirements  for  future  preliminary  design  of  MPS.  This  process 
identified  technology  voids  and  provided  the  ability  to  prioritize  the  voids  in  available 
software.  The  method  that  was  used  to  perform  the  survey  is  depicted  in  Figures  3-11 
and  3-12. 
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Figure  3-10.  Level  tbe  Load 
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The  State-of-the-Art  Survey  was  conducted  for  MPS  via  a  questionnaire,  which  was  devel¬ 
oped  to  identify  interfaces  and  relationships  of  planning  and  control.  The  survey  was  con¬ 
ducted  over  a  period  of  two  months  to  ensure  sufficient  industry  feedback  and  coverage.  The 
sources  of  data  were  evaluated  in  order  to  identify  and  provide  a  lasis  for  needed  technology 
developments. 

An  initial  list  of  47  potential  software  suppliers  was  assembled,  from  which  a  mailing  list 
of  17  was  considered.  The  survey  document  and  mailing  list  were  presented  to  the  Air  Force 
for  approval.  Each  company  on  the  list  was  contacted  by  phone  prior  to  the  mailing  to  deter¬ 
mine  whether  it  would  complete  tiie  survey.  A  specific  individual  was  identified  at  each  com¬ 
pany  to  receive  the  survey  and  serve  as  a  contact  for  verification  of  receipt  and  any  other  re¬ 
quired  coordination. 

Of  the  17  companies  selected  for  the  State-of-the-Art  Survey,  nine  actually  responded. 
3.2.6.2  Weighted  Analysis  Technique 

There  were  approximately  15  questions  per  topic  (150  questions  total)  in  the  question¬ 
naire.  A  scale  for  responding  was  included  tor  each  question.  The  scale  consisted  of  three 
major  points:  “not  at  all”  (low  end  of  scale),  “partial”  (midpoint),  and  “complete”  (high 
end),  indicating  the  degree  to  which  a  particular  topical  question  was  covered  by  a  vendor’s 
software. 

Following  the  receipt  of  the  vendor’s  completed  survey,  the  answers  were  weighted  by  as¬ 
signing  values  from  0  to  4  to  the  graduations  cn  the  scale  (see  Figure  3-13). 

Each  respondent’s  check  mark  on  the  scale  was  analyzed  and  a  corresponding  value  was 
assigned.  Every  question  included  within  a  functional  area  could  be  rated  at  most  a  value  of 
4;  hence,  if  there  were  15  questions  in  a  particular  functional  area,  the  maximum  score  would 
be  60.  Therefore,  if  a  particular  respondent  checked  “partial”  for  every  question,  the 
respondent’s  score  would  be  30. 

The  resulting  percentage  of  the  SOA  available  from  that  respondent  for  that  functional 
are?,  would  be  50%,  as  calculated  by  the  following  equation: 

%  wa  RESPONDENT  SCORE  m 
SOA  Total  Score  Possible  X  100 

The  final  state-of-the-art  (SOA)  document  SAR  550150000  contains  the  scores  for  all 
respondents  for  a  particular  functional  area  on  those  figures  entitled,  “Weighted  Values  for 
Each  Question  and  Percentage  SOA  Available  by  Respondent.”  In  addition,  the  resulting  per¬ 
centage  representing  the  amount  of  the  state-of-the-art  software  that  the  respondent  currently 
has  available  is  displayed  in  graphic  form  in  the  same  document. 

A  summary  of  respondents’  available  software  functionality  they  thought  could  satisfy  the 
major  15  categories  of  technologies  appears  in  Figure  3-14. 
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Figure  3-13.  Weighted  Scale 
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Figure  3-14.  PerceuUge  of  Functionality  Rented  in  the  State-of- 
the-Art  Surrey  for  *11  Respondents 
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3.3  TASK  3.  SUBTASK  1:  DEVELOP  AND  UNDERSTAND  THE  PLAN 
PRODUCTION  SUBTASK  (PPS)  PROBLEM 

3.3.1  Understand  the  Problem  Plan 

A  ccompHshments 

A  detailed  plan  was  developed  with  General  Dynamics  and  General  Electric  to  perform  re¬ 
quirements  definition.  Needs  Analysis,  and  state-of-the-art  assessment  of  the  “As-Is”  PPS 
arena  with  emphasis  on  the  formulation  of  improvement  concepts  for  the  PPS  task.  The  plan 
included  training,  data  collection  techniques,  model  building,  validation  process,  analysis,  and 
state-of-the-art  review. 

The  scope  of  the  PPS  study  effort  was  developed  in  the  form  of  an  IDEF0  kit  and  was 
used  by  General  Dynamics  and  General  Electric  as  the  guide  for  understanding  the  PPS  prob¬ 
lem. 

3.3.2  Task  3,  Subtask  2:  Analyze  Needs  for  PPS 
3J1.2.1  PPS  Needs  Analysis 

Accomplishments 

A  Needs  Analysis  was  completed  for  the  PPS  task.  An  understanding  of  the  functional  re¬ 
quirements,  computer  application  strategies,  interface  requirements,  and  problems  was  devel¬ 
oped.  Needs  were  prioritized  based  on  established  criteria  such  as  cost  drivers,  potential 
benefits,  and  human  factors.  The  primary  needs  identified  in  the  PPS  arena  by  General 
Dynamics  were  as  follows: 

•  Reconciliation  of  Engineering  Releases 

•  Automated  Assembly  Part  Planning 

•  Automated  Detail  Part  Planning 

•  Automated  Application  of  Work  Measurement  Standards 

•  Valid  and  Accurate  Facilities  and  Resource  Management  Information 

The  above  needs  for  PPS  were  prioritized  and  used  in  the  development  of  improvement 
concepts  design  for  IPS. 

If  the  needs  for  PPS  could  be  satisfied,  a  savings  of  Si  Million  would  be  possible. 

The  detailed  Needs  Analysis  for  PPS  was  documented  in  the  second  IPS  interim  report 
(ITR550150002U). 

3.3.3  Task  3,  Subtask  3:  Build  “As-ls”  PPS  Factory  View 
3.3.3. 1  PPS  Function  and  Information  Models 
Accomplishments 

An  IDEFo  function  model  and  an  IDEF|  information  model  were  constructed  based  on 
the  priorities  established  in  the  Needs  Analysis.  It  was  determined  that  the  results  of  the  Plan 
Production  modelling  area  encompassed  the  major  needs  identified  for  PPS. 
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Based  on  the  modelling  efforts,  the  function  and  information  models  concentrated  on  the 
Reconciliation  of  Engineering  Release  arena.  The  top  view  of  the  function  model  is  refer¬ 
enced  in  Figure  3-15  labeled  SMS l,  and  Figure  3-16,  labeled  SMS2. 

The  information  model  overview  is  referenced  in  Figure  3-17. 

The  complete  IDEF0  function  model  kit  number  AIM  550153100  and  the  IDEFj  informa¬ 
tion  model  kit  number  AIM  550153200  are  available  in  the  ICAM  library. 

The  process  of  PPS  factory  modeling  added  34  bottom-level  nodes  to  the  Manufacturing 
Architecture  MFG0.  These  added  nodes  were  a  result  of  a  further  breakdown  of  activities 
“Control  Planning”  and  “Determine  Detail  Method  of  Manufacture.” 

3.3.4  Task  3,  Subtask  4:  Build  “As-Is”  Composite  PPS  Factory  View 

3.3.4.1  PPS  Composite  Factory  View 
Accomplishments 

Using  the  completed  General  Dynamics  factory  view  of  PPS,  the  balance  of  the  coalition 
provided  their  IDEF0  and  IDEF]  data  and  models  of  PPS.  This  process  provided  a  formal  re¬ 
view  and  consensus  that  led  to  concurrence  of  the  coalition  on  the  final  composite  view 
models  of  PPS. 

The  composite  modeling  approach  for  PPS  was  similar  to  the  process  identified  in  para¬ 
graph  3.2.4  for  MPS. 

3.3.5  Task  3,  Subtask  5:  Formulate  Improvement  Concepts  for  PPS 

3.3.5.1  PPS  Improvement  Concepts 
Accomplishments 

The  improvement  concepts  prioritized  for  PPS  were  developed  from  a  major  category  list 
of  15  technologies.  The  results  of  this  analysis  indicated  that  the  most  important  improve¬ 
ments  in  PPS  technology  were: 

•  Level  Shop  Load 

•  Effectivity  Change  Control 

The  composite  “As-Is”  factory  model  for  PPS  was  used  to  determine  improvement  con¬ 
cepts  for  further  study  and  evaluation.  The  process  by  which  the  improvement  concepts  were 
developed  for  PPS  was  similar  to  the  technique  used  for  MPS  in  paragraph  3.2.5.I. 

The  detailed  information  related  to  PPS  improvement  concepts  is  included  in  the  third  IPS 
interim  report  (ITR550150003U). 

3.3.6  Task  3,  Subtask  6:  Review  State  of  the  Art  for  PPS 

3.3.6.1  PPS  State-of-the-Art  Survey 
A  ccomplishments 

The  State-of-the- \rt  Survey  was  conducted  for  PPS  via  a  questionnaire.  The  process  for 
development  of  the  questionnaire  and  the  survey  technique  was  similar  to  MPS  para¬ 
graph  3.2.6.  The  responses  received  regarding  Effectivity  Change  Control  for  engineering 
changes  indicated  a  lack  of  accountability  and  traceability  in  the  various  software  packages  re¬ 
viewed. _ 


Figure  3*15.  Plan  Production 


Figure  3-16.  Plan  Production 


A3  “PLAN  PRODUCTION 
IDEF  1  OVERVIEW 


Figure  3-17.  A3  “Plan  Production”  IDEF,  Overview 
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This  input  provided  a  high  order  of  priority  for  development  of  this  technology  void  for 
system  design  of  IPS.  A  complete  copy  of  the  survey  questions  are  contained  in  the  third  IPS 
interim  report  (ITR55015G003U). 

3.4  TASK  4,  SUBTASK  1:  DEVELOP  AND  UNDERSTAND  THE  PLAN  FOR 
MANUFACTURE  SUBTASK  (PMS)  PROBLEM 

3.4.1  PMS  Understand  the  Problem  Plan 
Accomplishments 

A  detailed  plan  was  developed  with  Northrop  Corporation  and  General  Electric  to  perform 
requirements  definition.  Needs  Analysis,  and  state-of-the-art  assessment  of  the  “As-Is”  PMS 
arena  with  emphasis  on  the  formulation  of  improvement  concepts  for  this  task.  The  plan  in¬ 
cluded  training,  data  collection  techniques,  model  building,  validation  process,  analysis,  and 
state-of-the-art  review. 

3.4.2  Task  4,  Subtask  2:  Analyze  Needs  for  PMS 
14.2.1  PMS  Needs  Analysis 

Accomplishments 

A  Needs  Analysis  was  completed  for  the  PMS  task.  An  understanding  of  the  functional 
requirements,  computer  application  strategies,  interface  requirements,  and  problems  was  de¬ 
veloped.  Needs  were  prioritized  based  on  established  criteria  such  as  cost  drivers,  potential 
benefits,  and  human  factors.  The  primary  needs  identified  in  the  PMS  arena  by  Northrop 
Corporation  were  as  follows: 

•  Tooling  History  and  Tooling  Engineering  Data 

•  Development  of  Selected  Structure  and  Method  of  Manufacture 

•  Valid  Engineering  Output 

•  Capability  to  Assemble  and  Disseminate  Product  Design  Release  Schedules 

•  Budget  Preparation 

•  Available  Capability  and  Performance  Status 

•  Flexible  Retrieval  of  Information 

•  Consistent  Application  of  Time  Standards 

•  Responsive  Manual  Systems 

•  Control  of  Engineering  Changes 

The  above  needs  indicated  a  potential  savings  in  excess  of  $2  million. 

The  needs  for  PMS  were  prioritized  and  used  in  the  development  of  component  concept 
design  for  PMS.  The  detailed  Needs  Analysis  for  PMS  was  documented  in  the  second  IPS  in¬ 
terim  report  (ITR550150002U). 
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3.4*3  Task  4,  Subtask  3:  Build  “As-Is”  PMS  Factory  View 

3.4.3.1  PMS  Function  and  Information  Models 
Accomplishment s 

An  IDEFo  function  model  and  an  IDEF,  information  model  were  constructed  based  on 
the  priorities  established  in  the  Needs  Analysis.  It  was  determined  that  Control  of  Engineer¬ 
ing  Changes  and  historical  information  would  establish  the  modeling  activity. 

Based  on  this  decision,  the  function  and  information  modeling  effort  concentrated  in  the 
above  areas. 

The  top  view  of  the  function  model  is  referenced  in  Figure  3-18,  labeled  WPI1,  and  Fig¬ 
ure  3-19,  labeled  WP12.  The  information  model  overview  is  referenced  in  Figure  3-20,  la¬ 
beled  WP42. 

The  complete  IDEFo  function  model  kit  number  AIM550I51100  and  the  IDEF)  informa¬ 
tion  model  kit  number  AIM  550151200  are  available  in  the  ICAM  library. 

The  process  of  PMS  factory  modeling  added  32  bottom-level  nodes  to  the  Manufacturing 
Architecture  MFGo-  These  added  nodes  were  a  result  of  a  further  breakdown  of  activities  in 
the  Estimate  Resource  Needs  and  Development  of  a  Production  Plan. 

3.4.4  Task  4,  Subtask  4:  Build  “As-Is”  Composite  PMS  Factory  View 

3.4.4. 1  PMS  Composite  Factory  View 

Accomplishments 

A  PMS  Composite  Factory  View  was  completed. 

Using  the  completed  Northrop  Corporation  factory  view  of  PMS,  the  balance  of  the  coali¬ 
tion  provided  their  IDEFo  and  IDEF!  data  and  models  of  PMS.  This  process  provided  a  for¬ 
mal  review  and  consensus  that  led  to  concurrence  of  the  coalition  on  the  final  composite  view 
models  of  PMS. 

The  composite  modeling  approach  used  by  General  Electric  and  its  coalition  was  similar  to 
the  MPS  process  described  in  paragraph  3.2.4. 

3.4.5  Task  4,  Subtask  5:  Formulate  Improvement  Concepts  For  PMS 

3.4.5.1  PMS  Improvement  Concepts 
Accomplishments 

The  improvement  concepts  prioritized  for  PMS  were  from  a  major  category  list  of  15  tech¬ 
nologies.  The  results  of  this  analysis  indicated  that  the  most  important  improvements  in  PMS 
technology  were: 

•  Control  of  Engineering  Change 

•  Available  Capability  and  Performance  Status 

The  composite  “As-Is”  factory  model  for  PMS  was  used  to  determine  improvement  con¬ 
cepts  for  further  study  and  evaluation.  The  process  by  which  the  improvement  concepts  were 
developed  for  PMS  was  similar  to  MPS  described  in  paragraph  3.2.5. 


Figure  3-18.  Plan  for  Manufacture 
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The  total  development  details  related  to  PMS  improvement  concepts  are  included  in  the 
15  major  technologies  contained  in  the  third  IPS  interim  Report  (ITR550150003U). 

3.4.6  Task  4,  Subtask  6:  Review  State  of  the  Art  for  PMS 

3.4.6.1  PMS  State-of-the-Art  Survey 
Accomplishments 

The  state-of-the-art  process  for  PMS  was  similar  to  MPS  described  in  paragraph  3.2.6. 
The  responses  regarding  Engineering  Change  Control  and  Historical  Capability  indicated  a 
technology  void  in  available  software  packages  reviewed. 

This  input  provided  the  information  needed  to  design  the  IPS  system.  A  complete  copy  of 
the  survey  questions  is  contained  in  the  third  IPS  interim  Report  (ITR550150003U). 

A  state-of-the-art  document  was  published  with  the  total  results  of  the  survey  for  MPS, 
FPS,  and  PMS.  The  document  number  is  SAR5501 50000,  and  it  is  available  in  the  ICAM  li¬ 
brary. 

3.5  TASK  5,  SUBTASK  1:  DEVELOP  AND  FORMULATE  IPS  DESIGN 

3.5.1  IPS  Design  Plan 
Accomplishments 

A  preliminary  and  detailed  design  plan  was  established  for  IPS.  The  plan  made  provision 
for  analyzing  the  preliminary  design  results  and  modified  the  configuration  as  required  to  es¬ 
tablish  an  IPS  prototype  system.  The  preliminary  design  included  the  development  of  a  Sys¬ 
tem  Specification  (SS)  and  System  Design  Specification  (SDS)  for  the  IPS  prototype  system. 

The  SS  and  SDS  provided  the  basis  for  the  IPS  prototype  detail  design. 

3.5.2  Task  5,  Subtask  2:  Establish  Preliminary  Design 
3.5.2.1  IPS  Preliminary  Design 

Accomplishments 

Preliminary  design  IDEFo  models  were  constructed  to  identify  the  major  IPS  prototype 
modules  and  interfaces  that  would  require  development, specifications.  The  top-level  prelimi¬ 
nary  design  “To-Be”  IDEF0  is  contained  in  Figure  3-21,  labeled  RDN  10,  Figure  3-22,  la¬ 
beled  RDN  12,  and  Figure  3-23,  labeled  RDN  13.  The  complete  preliminary  design  kit  is 
IPS-OT-2  and  is  on  file  in  the  ICAM  library. 

To  help  understand  the  performance  measures  and  dynamics  of  the  IPS  prototype  system, 
a  series  of  dynamics  models  was  built  using  IDEF2  methodology.  The  models  were  devel¬ 
oped  to  address  the  areas  of  scheduling  and  loading  of  manufacturing  resources.  The  models 
were  constructed  at  General  Dynamics  and  Rockwell  International  to  help  understand  the 
mechanisms  and  dynamics  of  these  technologies  and  to  verify  the  performance  measures  re¬ 
quired  to  build  systems  to  accommodate  actual  production  environments.  A  total  of  five 
models  were  built  and  are  available  in  the  ICAM  library.  The  intention  was  to  simulate  the 
dynamics  models  on  the  Integrated  Decision  Support  System  (IDSS)  for  validation  and 
evaluation. 


FTR550150000U 
30  November  1984 


30  November  1984 


The  five  models  and  their  purposes  are  as  follows: 


IDEF'  Model  Name 

Engineering  Release/ MRP  List 
Reconciliation  Process  at 
General  Dynamics 


Purpose 

To  illustrate  the  dynamic  process 
behavior  of  the  reconciliation  of 
engineering  releases  with  MRP 
lists  in  the  current  “As-Is" 
environment. 


Sheet  Metal  I/R  Panel 
Manufacturing  Cell  at 
General  Dynamics 


To  examine  the  effect  of 
alternate  manpower  levels  upon 
throughput  of  the  1R  panel 
manufacturing  cell. 


•  Rockwell  Interna'ional's 
Engineering  drawing 
Encoding  Process 


•  To  translate  Rockwell 
International's  engineering 
drawing  encoding  process 
into  an  IDEF2  model. 


•  Rockwell  International’s 
Order  Release  Process 


To  examine  the  effect  of 
various  production  policies 
upon  manpower  loading  in  the 
release  of  engineering  orders. 


•  The  effect  of  Lot  Sizing 
Policies  and  Multi-Year 
Aircraft  buys  upon  shop 
floor  labor  and  inventory 
costs  at  Rockwell  International 


•  To  illustrate  the  po*ential 
for  cost  savings  because  of 
various  lot  sizing  policies 
and  multi-year  aircraft  buys. 


3. 5.2.2  Simulation  Problems 
Problems  Encountered 

The  early  product  of  IDSS  was  unable  to  support  the  simulation  requirements  necessary  to 
process  the  dynamics  models  built. 

3.5.2.3  Simulation  Solution 
Solution/Approach  to  Problem 

Operation  Flow  Diagrams  /OFD)  were  built  by  simulation  analysts  and  manufacturing 
scheduling  and  planning  experts  who  analyzed  the  dynamics  through  the  modeling  process 
and  recommended  performance  measures,  including  response  time,  volume  of  data,  accuracy 
etc.  for  the  IPS  prototype  design. 
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3.S.2.4  IPS  System  Specification 
Accomplishments 

A  System  Specification  (SS)  was  developed  and  refined  for  the  IPS  prototype  system.  This 
document  detailed  the  requirements  contained  in  the  Systems  Requirement  Document 
(SRD).  The  functional  requirements  of  the  system  were  prioritized  based  on  estimated 
benefits.  Technology  voids  were  enumerated  for  each  of  the  following  requirements: 

•  Level  Loading 

The  major  technology  voids  associated  with  level  loading  involve  software  needed  to 
provide  timely  feedback  regarding  existing  resource  load  status,  and  the  capability  to 
combine  information  about  factory  load  with  planned  load  not  yet  released  to  the  facto¬ 
ry.  Software  voids  between  the  planning  systems  above  the  factory  and  control  systems 
within  the  factory  make  it  impossible  to  provide  automatic  interfaces.  Available 
software  capable  of  performing  level  toadi“<t  have  not  been  proven  for  large  volumes  of 
parts,  do  not  provide  dynamic  queue-size  determination,  and  cannot  dynamically  dispose 
of  the  inevitable  need  for  load  changes. 

•  Effective  Control  cf  Capacity  and  Resources 

The  technology  void  in  effective  control  of  capacity  and  resources  is  the  lack  of  capa¬ 
bility  to  obtain  feedback  and  status  that  would  measure  the  impact  of  a  schedule  on 
resources  prior  to  a  release  to  the  factory.  In  addition,  software  capability  to  automati¬ 
cally  evaluate  the  factory’s  capacity  to  fulfill  a  production  schedule,  automatically 
reschedule  released  orders,  and  provide  new  work  packages  is  not  available. 

•  Experience  and  Capability  (E&C) 

The  major  void  in  state-of-the-art  software  is  the  inability  to  interface  the  sources  of 
status,  performance  information,  and  problems  as  feedback  to  higher-level  systems  for 
use  in  effective  plannning  and  control.  The  specific  technology  voids  include  structures 
for  classification  of  information,  standardization  of  information  formats  between  the 
hierarchical  structures  of  planning  and  control  authority  and  responsibility,  and  software 
systems  that  provide  the  interfaces  necessary  for  E&C  information  flow  from  its  source 
to  the  using  functions. 

•  Control  Concepts 

The  technology  void  in  the  area  of  control  concepts  indicated  improved  accuracy  for 
production  requirements  must  be  created  for  release  to  the  factory.  This  requires  a 
means  of  converting  higher-level  schedules  to  requirements  for  sub-assemblies  and  fab¬ 
ricated  parts.  An  evaluation  must  be  made  of  the  probability  that  sufficient  capacity  ex¬ 
ists  to  accomplish  the  load  on  the  factory.  An  orderly  means  of  ptimally  releasing 
work  to  the  factory  is  required  to  assure  that  sufficient  work  has  been  released,  but  not 
so  much  as  to  allow  manipulation  within  the  factory  that  might  result  in  excess  buildup 
of  inventory  and  not  meeting  predetermined  required  dates.  Integration  through  com¬ 
mon  information  reference  and  timely  feedback  is  necessary  to  tie  together  the  hierar¬ 
chy  of  planning  and  control.  This  is  essential  to  providing  timely  feedback  from  the  fac¬ 
tory  as  to  how  the  load  is  (or  is  not)  being  achieved. 

The  SS  outlined  the  functions,  interfaces  and  data  requirements  for  building  an  IPS  pro¬ 
totype  system.  The  SS  is  available  as  document  number  SS5501 50000,  on  file  at  the 
ICAM  library. 
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3. 5. 2. 5  IPS  Systems  Design  Specification 
Accomplishments 

A  System  Design  Specification  was  developed  further  refining  the  requirements  presented 
in  the  System  Requirements  Document  and  the  SS  for  the  "To-Be”  prototype  system. 

The  mission  of  the  "To-Be”  system  was  to  develop  a  Production  Planning  and  Control 
System  (PP&CS)  that  would  have  the  ability  to  interact  both  internally  between  the  functional 
areas  and  externally  to  those  systems  with  which  it  was  expected  to  interface.  This  would  in¬ 
clude  the  utilization  of  common  data  between  the  related  systems  (PP&CS  modules  and  relat¬ 
ed  external  interfaces). 

To  further  identify  the  requirements  of  the  prototype  system,  a  breakdown  of  individual 
configuration  items  (CIs)  was  developed.  The  CIs  to  satisfy  the  system  requirements  were  as 
follows: 

1.  Manufacturing  Parts  List  (PL)  Control  Module 

This  module  provides  the  capability  to  verify  that  parts  lists  exist  for  al'  master  produc¬ 
tion  schedule  items  to  be  processed. 

2.  Gross  Requirements  Module 

This  module  extends  gross  requirements  within  effectivity  (Configuration  Control)  from 
the  master  production  scnedule  items. 

3.  Adjustment  Module 

This  module  provides  adjustments  to  requirements  quantities  for  process  loss. 

4.  Net  Requirements  Module 

This  module  converts  gross  requirements  to  net  requirements  in  consideration  of  any 
available  inventory  and/or  open  orders. 

5.  Lot  Size  Module 

This  module  produces  lot  sizes  from  net  requirements  according  to  predetermined  poli¬ 
cies. 

6.  Capacity  Profile  Module 

This  module  explodes  labor  for  loading  and  comparison  to  available  capacity  across  the 
manufacturing  planning  horizon. 

7.  Factory  Order  Release  Module 

This  module  releases  production  requirements  to  the  factory  based  on  earliest  start  date 
and  in  consideration  of  the  maximum  amount  of  load  to  be  maintained  in  the  factory. 

8.  Production  Information  Control  Module 

This  module  receives,  validates,  and  provides  information  used  and/or  created  by  the 
PP&CS  system. 

9.  Resultant  Processing  Module 

This  module  conditions  performance  information,  provides  performance  measures,  and 
projects  future  factory  performance. 
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10.  Intra-System  Communications  Module 

This  module  controls  the  sequencing  of  the  PP&CS  system  priorities  and  software  steps. 
It  provides  the  ability  to  pass  intermediate  information  formats  between  the  PP&CS  sys¬ 
tem  modules.  It  also  provides  data  protection  and  recovery  procedures  to  reinitiate  job 
steps  from  pre-established  recovery  points. 

11.  Inter-System  Communications  Module 

This  module  provides  the  ability  to  receive  information  such  as  the  master  production 
schedule  and  parts  lists  and  stock  balances  from  other  systems.  It  also  provides  informa¬ 
tion  such  as  factory  order  releases  to  other  systems. 


A  process  of  grouping  CIs  was  conducted  to  provide  a  modular  approach  to  the  system 
design  effort.  Figure  3-23,  labeled  RDN  13,  was  the  final  product  of  grouping  CIs  into  sys¬ 
tem  modules  for  further  detail  design. 

After  an  extensive  search  and  analysis  of  vendor-available  packages  and  software,  it  was 
decided  to  buy  an  MRP  module  that  would  include  the  CIs  1-5.  SDS  detailed  the  modules 
that  would  be  developed  in  detailed  design  to  satisfy  a  PP&CS.  These  modules  were 
identified  as  follows: 

CI6  -  Perform  Factory  Loading 

CI7  -  Release  Production  Requirements 

C18  -  Record  and  Provide  Production  Information 

CI9  -  Perform  Resultant  Processing 

CIs  10  and  11  were  defined  as  links  to  interface  within  the  PP&CS  system  and  externally 
to  outside  system  interfaces  (such  as  the  MCMM  shop  floor  control  system).  See  Fig¬ 
ure  3-24. 

The  SDS  is  available  as  document  number  SDS  550150001  on  file  in  the  ICAM  library. 
3.5.1.6  PP&CS  Development  Specifications  (DS) 

Accomplishments 

A  Development  Specification  (DS)  was  prepared  for  each  Cl  to  be  designed.  The  DS  de¬ 
scribed  the  user  interface,  functional  requirements,  information  requirements,  inputs,  pro¬ 
cessing  descriptions,  and  outputs  for  each  CL 

To  achieve  the  PP&CS  detailed  design,  these  specifications  were  constructed: 

CI-6  Perform  Factory  Loading 

CI-7  Release  Production  Requirements 

CI-8  Record  and  Provide  Production  Information 

CI-9  Perform  Resultant  Processing 

CI-1 1  Interface  to  External  Functions 

The  following  is  a.  brief  discussion  of  each  specification: 
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Figure  3-24.  Production  Planning  and  Control  System 
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3. 5. 2.7  Factory  Loading  Development  Specification 

Accomplishments 

The  CI-6  Perform  Factory  Loading  DS  describes  the  detail  sequence  loading  and  balancing 
of  the  factory.  This  process  is  accomplished  within  limits  of  available  capacity  identified  by 
the  manufacturing  planning  function.  This  module  is  the  heart  of  the  prototype  system. 

Production  requirements  are  compared  to  production  instructions  (process  routings)  to  ex¬ 
plode  labor  which  will  be  used  to  load  manufacturing  resources. 

Two  attempts  are  made  to  validate  the  load  within  the  required  schedule:  long  term  and 
short  term.  The  initial  pass  is  for  a  longer  horizon  that  summarizes  and  balances  the  load  for 
the  factory  by  resource  within  periods.  The  purpose  of  the  longer  horizon  is  to  solve  the  ca¬ 
pacity  problem  through  leveling  and  balancing  the  load.  Assuming  a  successful  summary 
loading,  a  shorter  horizon  may  be  selected  for  detail  sequence  loading  and  balancing  at  the 
process  level  by  resource. 

It  is  not  necessary  to  run  long-term  loading  prior  to  running  short-term  sequence  loading 
and  balancing. 

The  long  and  short  term  loading  techniques  are  independent  algorithms.  The  major  func¬ 
tions  that  were  developed  in  detailed  design  for  eventual  construction  of  code  for  Factory 
Loading  are  as  follows: 

•  Long-Term  Loading  (LTL) 

•  Long-Term  Balancing  (LTB) 

•  Short-Term  Loading  (STL) 

•  Short-Term  Balancing  (STB) 

•  Simulation  Capability  (Schedule  Evaluator) 

The  CI-6  Factory  Load  development  specification  is  available  as  document  DS5501S02061 
on  file  in  the  ICAM  library. 

3. 5.2.3  Release  Production  Requirements  Development  Specification 

Accomplishments 

A  Development  Specification  for  the  preliminary  design  was  completed  for  CI-7  Release 
Production  Requirements.  The  objective  of  the  Release  Production  Requirements  functional¬ 
ity  is  to  effectively  meter  the  flow  of  work  to  the  shop  floor. 

Initial  functions  accept  the  detail  schedule  as  input  and  estimate  an  expected  release  date 
for  each  production  requirement  included  in  the  detail  schedule.  The  expected  release  date  is 
determined  by  taking  into  consideration  the  current  released  load  and  load  restrictions  (i.e., 
upper  and  lower  limits  on  the  amount  of  work  that  may  be  released)  for  each  resource 
defined  within  the  factory  hierarchy.  A  release  schedule,  displaying  release  dates  for  each 
production  requirement,  is  produced  and  may  be  displayed  by  the  user. 

This  Cl  also  identified  potential  adjustments  to  required  quantities  of  parts  for  production 
requirements.  For  example,  shortages  because  of  poor  yield  or  excesses  due  to  lot  sizing  may 
be  recorded  in  the  data  base  as  production  requirements  are  completed  on  the  shop  floor.  A 
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report  is  generated  that  identifies  ail  production  requirements  for  which  quantity  adjustments 
may  be  desired.  After  production  requirements  eligible  for  quantity  adjustment  have  been 
identified,  the  user  is  given  the  opportunity  to  actually  modify  required  quantities. 

The  user  is  also  given  the  ability  to  display  the  status  of  released  load  for  all  centers,  cells, 
stations,  and  processes  defined  within  the  factory  hierarchy.  Specifically,  a  conventional  for¬ 
matted  display  or,  optionally,  a  bar  chart  display  conveys  various  items  of  load  information  in¬ 
cluding  the  released  load,  released  load  upper  and  lower  iimits,  and  the  dispatched  load. 

The  user,  after  having  assessed  the  displayed  load  information,  may  then  select  one  or 
more  resources  to  which  production  requirements  will  be  released.  Production  requirements 
are  always  released  to  centers  within  the  factory,  but  the  user  is  given  the  option  of  identify¬ 
ing  underloaded  resources,  perhaps  at  a  lower  level  than  the  center  level,  for  which  produc¬ 
tion  requirements  are  to  be  released.  The  user  is  also  given  the  ability  to  specify  the  amount 
of  work  to  be  released  to  each  of  the  selected  resources. 

After  having  selected  resources,  the  user  is  then  given  the  option  of  analyzing  the  impact 
of  the  impending  release  on  all  resources.  That  is,  the  impact  of  having  specified  the  amount 
of  work  about  to  be  released  to  the  selected  resources  is  determined  without  actually  releasing 
production  requirements.  A  production  planner  is  thereby  able  to  more  accurately  predict 
overloads,  bottlenecks,  underloads,  etc.  and,  therefore,  is  better  able  to  identify  the  need  for 
overtime,  subcontracting,  or  reassignment.  Production  requirements  are  then  actually  released 
for  the  selected  resources  to  the  shop  floor. 

The  major  functions  were  detailed  in  the  DS  are  as  follows: 

•  Set  Release  Parameters 

•  Load  Production  Requirements 

•  Estimate  Release  Dates 

•  Display  Release  Schedu!  t 

•  Identify  Quantity  Adjustments 

•  Adjust  Production  Requirements 

•  Display  Load  Status 

•  Select  Resources  for  Release 

•  Analyze  Release  Impact 

•  Release  Production  Requirements  for.  Selected  Resources 

The  DS  for  CI-7  Release  Production  Requirements  included  the  functionality,  inputs,  user 
interface,  data  requirements,  and  outputs  for  the  above-listed  functions. 

Because  of  the  site-specific  requirements  of  a  release  module  in  the  different  aerospace 
companies  a  decision  was  made  by  the  Air  Force  and  General  Electric  to  prepare  dt  Ailed 
software  design  information  for  this  module  and  not  to  proceed  with  implementation. 

The  DS  for  CI-7  Release  Production  Requirements,  DS550153071,  is  available  in  the 
ICAM  library. 
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3.S.2.9  Record  and  Provide  Production  Information  DS 

Accomplishments 

The  CI-8  Record  and  Provide  Production  Information  DS  was  developed.  It  described,  the 
function  '  information  data  requirements,  inputs,  processing  rules  and  algorithms,  user  inter¬ 
face,  anu  outputs. 

The  primary  objective  of  this  Cl  is  to  record  and  provide  production  information.  The 
recording  of  information  pertains  to  data  that  is  required  to  support  factory  loading,  release  of 
production  requirements,  and  resultant  processing.  This  includes  information  which  is  not 
available  through  interfacing  systems.  Additionally,  thp  initialization  and  maintenance  of  this 
information  does  not  constitute  a  mainstream  function  of  any  of  these  system  modules.  This 
Cl  also  addresses  providing  manufacturing  management  with  information  to  support  decision 
making.  Again,  the  provision  of  this  information  does  not  fall  within  the  mainstream  activi¬ 
ties  of  the  CIs  listed  above. 

This  function  receives  factory  environment  information  in  addition  to  planned,  actual,  and 
performance  information.  Factory  information  is  obtained  from  the  organization  responsible 
for  the  factory  configuration.  Planned  information  is  obtained  through  the  planning  functions. 
Actual  production  information  is  obtained  from  the  factory.  Performance  information  is  ob¬ 
tained  from  Perform  Resultant  Processing  CI-9. 

All  information  is  validated  for  correct  format  and  content  If  valid,  the  information  is 
stored  and  retrieved  upon  request.  Invalid  inputs  are  appropriately  handled  through  error 
processing  routines.  Production  requirements  are  provided  and  status  information  is  report¬ 
ed. 

The  major  functions  that  were  described  in  detail  were  as  follows: 

•  Define  Factory  Levels 

•  Define  Factory  Resource 

•  Display  Factory  Hierarchy 

•  Define  Machine  Type 

•  Delete  Factory  Resource 

•  Delete  Machine  Type 

•  Define  Capacity 

•  Display  Capacity 

•  Maintain  Shop  Calendar  Parameters 

•  Maintain  Shop  Calendar 

•  Display  Shop  Calendar 

•  Define  Move  Times 

•  Adjust  Load  Parameters 
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The  preliminary  design  of  the  above  functions  were  provided  to  the  detailed  design 
Task  5,  Subtask  3. 

The  DS  for  CI-8  Record  and  Provide  Production  Information,  DS55Q154081,  is  available 
in  the  ICAM  library. 

3.5.2.10  Perform  Resultant  Processing  DS 

Accomplishments 

The  CI-9  Perform  Resultant  Processing  DS  was  completed  for  the  preliminary  design 
phase. 

The  primary  objective  of  this  Cl  is  to  accumulate  actual  performance  data  from  the  facto¬ 
ry,  establish  performance  characteristics,  measure  those  characteristics  against  plan  and  histor¬ 
ical  performance,  and  report  trends  and  deviations. 

Initially,  factory  feedback  data  is  validity-checked  and  then  various  performance  measures 
are  calculated  to  characterize  the  performance.  The  measures  used  emphasize  values  normal¬ 
ized  against  plan  values  that  can  then  be  used  for  comparison  across  jobs,  machines,  and 
time.  The  performance  measures  calculated  are  summarized  across  jobs  and  over  time  to  ob¬ 
tain  average  performance  for  part  numbers  and  operations,  machines  for  all  parts,  and  subo¬ 
peration  plans  across  jobs  and  in  the  manufacturing  hierarchy  over  time.  The  performance  of 
the  factory  is  summarized  -s  a  function  of  time  to  provide  periodic  information  by  day,  week, 
month,  quarter,  and  year,  as  appropriate.  Longer-term  trend  measures  are  calculated 
corresponding  to  each  time  period.  The  operation  plan,  machine,  and  factory  performance 
are  analyzed  to  determine  significant  trends  and  changes.  A  general  statistical  analysis  capabil¬ 
ity,  IDSS,  is  provided  to  allow  the  historical  data  to  be  accessed  and  analyzed.  Finally,  a  capa¬ 
bility  is  provided  to  allow  the  user  to  recommend  changes  to  the  performance  standards  that 
will  be  used  in  the  operation  plans. 

The  major  functions  described  in  the  Perform  Resultant  Processing  DS  are  as  follows: 

•  Validity  Check  Feedback  Information 

•  Calculate  Job-Related  Measures 

•  Calculate  Machine-Related  Measures 

•  Calculate  Move/Queue- Related  Measures 

•  Update  Historical  Performance 

•  Summarize  Performance  Information 

•  Summarize  Subplan  Performance 

•  Obtain  and  Summarize  Periodic  Information 

•  Analyze  Performance 

The  Perform  Resultant  Processing  DS  detailed  the  functional  and  information  data  re¬ 
quirements,  inputs,  processing  rules  and  algorithms,  and  outputs  for  the  above  functions. 

The  CI-9  Resultant  Processing,  DS  550152091,  is  available  in  the  ICAM  library. 
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3.5.111  PP&CS  Interface  DS 

Accomplishments 

A  CI-11  Interface  DS  was  developed,  describing  the  functional  and  information  data  re¬ 
quirements,  inputs,  processing  rules  and  algorithms,  user  interface,  and  outputs. 

The  primary  objective  of  this  DS  was  to  document  the  major  functions  responsible  for  in¬ 
terfacing  to  existing  manufacturing  application  systems  that  are  external  to  PP&CS. 

The  CI-11  Interface,  DS  550156111,  is  available  in  the  ICAM  library. 

3.5.2.12  PP&CS  Quality  Assurance  (QAP)  Plan 

Accomplishments 

A  Quality  Assurance  Plan  was  developed  to  formally  identify  QA  provisions  to  be  carried 
out  for  the  development  of  PP&CS  software. 

The  plan  was  prepared  in  accordance  with  QA  requirements  outlined  in  Mil  Spec 
MIL-5-52779 A,  entitled,  “Software  Quality  Assurance  Program  Requirements.” 

The  plan  described  provisions  addressing  specific  QA  requirements  for  PP&CS  software 
development.  In  particular,  QA  strategies  for  each  of  the  following  requirements  were  de¬ 
scribed: 

•  Tools,  Techniques,  and  Methodologies 

•  Computer  Program  Design 

•  Documentation 

•  Computer  Program  Library  Controls 

•  Reviews  and  Audits 

•  Configuration  Management 

•  Testing 

•  Corrective  Action 

The  quality  assurance  plan,  QAP550150001,  is  available  in  the  ICAM  library. 

3.5.2.13  PP&CS  System  Test  Plan 

Accomplishments 

A  System  Test  Plan  was  developed  for  PP&CS  to  provide  an  approach  for  monitoring  and 
controlling  the  testing  and  integration  of  PP&CS  software. 

It  was  planned  that  the  testing  of  PP&CS  be  broken  down  into  four  major  levels  that 
would  require  specific  tests  or  series  of  tests  to  ensure  that  each  level  met  the  requirements 
and  functional  specifications  that  were  previously  developed.  The  following  levels  of  test 
were  established: 
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Levels 


Type  cf  Testing 


System 

Configuration 

Transactions 

Programs 


System  Test  and  Validation 
Integration  Test 
Transaction  Test 
Unit  Test 


The  complete  System  Test  Plan,  STP550150001,  is  available  in  the  ICAM  library. 


3.5.3  Task  5,  Subtask  3:  Establish  Detailed  Design 

Accomplishments 

This  phase  of  the  project  resulted  in  the  development  of  four  product  specifications  con¬ 
structed  in  accordance  with  ICAM  documentation  standards.  These  specifications  document 
PP&CS  detailed  design  accomplishments  in  the  following  functional  areas: 

1.  Perform  Factory  Loading  —  (PS  550152061) 

2.  Record  and  Provide  Production  Information  —  (PS  550154081) 

3.  Release  Production  Requirements  —  (PS  550153071) 

4.  Perform  Resultant  Processing  —  (PS  550152091) 

The  PP&CS  detailed  design  effort  adhered  to  software  engineering  design  guidelines  and 
conventions  identified  for  the  IISS  test  bed  developed  under  ICAM  Project  Priority  6201M. 
A  summary  of  detailed  design  accomplishments  in  each  of  the  above  functional  areas  is 
presented  below. 

3.5.3.1  Perform  Factory  Loading  (PS  550152061) 

Accomplishments 

A  number  of  transactions  were  designed  in  support  of  the  Perform  Factory  Loading  func¬ 
tion  of  PP&CS.  Specifically,  detailed  design  documentation  for  the  following  transactions  was 
developed, 

1.  Prepare  MRP  Input 

Before  any  of  the  Factory  Loading  functions  concerned  with  the  analysis  of  manufacturing 
load  versus  capacity  can  be  executed,  it  is  first  necessary  to  properly  initialize  the  PP&CS  data 
base  with  planning  information  generated  from  an  MRP  system.  This  information  takes  the 
form  of  new  production  requirements  (i.e.,  net  requirements),  cancellations  to  (i.e.,  deletions 
of)  existing  production  requirements,  and  modifications  to  existing  production  requirements. 
Modifications  to  production  requirements  take  the  form  of: 

•  quantity  changes 

•  due  date  changes 

•  earliest  start  date  changes 

•  priority  changes 

Additions,  cancellations,  and  modifications  are  communicated  to  PP&CS  via  an  interface 
function  responsible  for  retrieving  appropriate  information  from  the  data  base  of  the  comrner- 
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rial  MRP  system.  Production  requirement  information  communicated  via  this  interface  func¬ 
tion  will  then  be  accessed  by  the  PREPARE  MRP  INPUT  function,  primarily  responsible  for 
initializing  and  modifying  the  PP&CS  data  base. 

This  function  was  designed  to  filter  the  data  by  detecting  production  requirements  identi¬ 
fying  parts  that  have  not  yet  been  defined  within  the  PP&CS  data  base  and  parts  for  which  no 
process  planning  information  has  yet  been  defined.  Appropriate  error  reports  car.  be  generat¬ 
ed  after  invoking  the  data  prep  function  which  also  executes  as  a  background  task. 

2.  Long-term  Loading  (LTL) 

The  primary  objectives  of  the  LTL  function  are: 

•  To  provide  the  capacity  planner  with  an  understanding  of  underloaded  and  overloaded 
resources  at  different  levels  of  the  factory  organizational  hierarchy,  e.g.,  departments, 
centers,  cells,  etc.  Such  information  then  serves  as  input  to  the  Long-Ieim  Balancing 
(LTB)  function  (described  subsequently),  whose  primary  responsibility  is  to  balance  or 
smooth  the  overloaded  planning  periods. 

•  To  provide  a  generic  system  with  respect  to  the  factory  hierarchy  that  could  be  used  in 
any  manufacturing  environment  involved  with  discrete  parts  production  (i.e.,  job  shop 
environment)  and/or  batch  assembly. 

A  data  flow  diagram  highlighting  the  major  activities  of  the  LTL  function  is  illustrated  in 
Figure  3-25. 

The  first  activity  is  responsible  for  gathering  appropriate  user  input,  including: 

•  load  method  (options  for  forward  or  backward  loading) 

•  horizon  start  and  end  dates 

planning  period  size  (fiscal  weeks,  months,  quarters  or  years) 

•  resources  for  which  operations  are  to  be  loaded 

Samples  of  screen  formats  for  the  LTL  user  interface  are  illustrated  in  Figures  3-26 
through  3-30.  In  particular,  the  screens  shown  perform  the  following: 

Figure  3-26  Prompts  user  to  select  method  by  which  loading  is  to  be  performed. 

Figure  3-27  Enables  user  to  soecify  the  planning  horizon  and  period  size. 

Figures  3-28,  3-29  and  3-30  illustrate  screens  enabling  the  user  to  restrict  the  loading  func¬ 
tion  to  specific  portions  of  the  factory  hierarchy  environment. 

The  second  activity  is  responsible  for  determining  which  of  the  production  requirements 
are  eligible  for  loading  (based  on  horizon  start  and  end  dates  identified  by  the  user)  and  dis¬ 
tributing  the  eligible  production  requirements  to  separate  files  to  facilitate  processing  by  the 
subsequent  activity. 

The  third  activity  is  multi-tasked  and  is  primarily  responsible  for  determining  which  opera¬ 
tions,  referred  to  as  “load  units  (LU),”  of  the  eligible  production  requirements  are  eligible  to 
be  loaded.  Operations  falling  prior  to  the  horizon  start  date  or  beyond  the  horizon  end  date 
will  not  be  included  in  the  load.  Each  task  performing  this  activity  generates  a  separate  file 
identifying  eligible  operations  and  the  planning  period(s)  to  which  it  must  be  associated. 
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Figure  3-26.  Long-Term  Loading 


Figure  3-27.  Long-Term  Loading 
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Figure  3-28.  Long-Term  Loading 
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Figure  3-29.  Long-Term  Loading 
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Fif  arc  3*39.  Loag-Tena  Loading 


The  fourth  activity  merges  the  files  produced  by  the  previous  activity.  The  merged  file  is 
then  sorted  by  Resources,  Machine  Types  (RMT),  and  Planning  Periods,  and  split  into  a 
number  of  subfiles  again  to  facilitate  processing  to  be  performed  by  the  following  task. 

The  fifth  activity  is  also  multi-tasked  and  performs  the  actual  loading  of  the  PP&CS  data¬ 
base,  i.e.,  the  association  or  connection  of  load  units  to  planning  periods  and  the  accumula¬ 
tion  of  load  versus  capacity  by  resource. 

3.  Long-term  Balancing  (LTB) 

The  objective  of  LTB  is  to  determine  which  planning  periods  are  overloaded  as  a  result  of 
LTL  and  to  balance  the  load  by  movinj  the  load  from  overloaded  periods  to  underloaded 
periods.  Data  flow  diagrams  highlighting  major  activities  incorporated  within  the  design  of 
LTB  are  illustrated  in  Figures  3-31  and  3-32.  Figure  3-32  represents  an  explosion  of  the  Per¬ 
form  Attempts  activity  shown  in  Figure  3-31. 

The  first  activity  in  Figure  3-31  retrieves  required  input  from  the  user.  Specifically,  it 
prompts  the  user  for  information  similar  to  that  described  for  LTL  above. 

The  second  activity  performs  a  modified  version  of  LTL  which  is  responsible  for  loading 
the  entire  factory.  LTL,  as  described  in  the  previous  subsection,  performs  an  ‘analysis’* 
function  enabling  the  user  to  determine  problem  perioda  without  incurring  unnecessary  data¬ 
base  overhead.  In  other  words,  via  the  LTL  transaction  it  is  possible  for  the  user  to  limit  the 
scope  of  the  function  to  a  subset  of  critical  or  “bottleneck”  resources  that  perhaps  have  his¬ 
torically  been  characterized  with  capacity  problems  for  a  particular  manufacturing  environ¬ 
ment.  The  comparable  activity  in  LTB  loads  all  factory  resources  and  in  effect  prepares  the 
data  base  for  the  ensuing  balancing  activities. 
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Figure  3-31.  Long-Term  Factory  Load  Balancing 


lire  3-33.  Short-Term  Loading  Major  Activities 
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The  third  activity  in  Figure  3-31  is  the  activity  responsible  for  initiating  the  actual  balanc¬ 
ing  function.  Specifically,  this  activity  identifies  ail  resource  machine  type  (RMT)  combina¬ 
tions  that  were  determined  (by  the  previous  activity)  to  be  overloaded.  Activity  4  then  splits 
this  group  of  resource  machine  type  combinations  into  subsets  according  to  high-level 
manufacturing  centers.  This  facilitates  multi-tasking  to  be  performed  by  the  perform  at¬ 
tempts,  Activity  5,  exploded  in  Figure  3-32.. 

The  last  bubble  of  Figure  3-31  Activity  6  is  responsible  for  summarizing  load  versus  ca¬ 
pacity  information  for  the  entire  factory  hierarchy. 

4.  Short-term  Loading  (STL) 

STL,  much  like  LTL,  also  provides  the  capacity  planner  with  an  understanding  of  under¬ 
loads  and  overloads  of  capacity.  LTL,  however  deals  with  higher-level  organizations  (see  Fig¬ 
ure  3-40),  i.e.,  “resources”  within  the  factory  hierarchy  and  larger  period  sizes,  e.g.,  weeks, 
months,  or  quarters.  Unlike  LTL,  STL  places  load  units  onto  specific  machines  for  a  specific 
day  in  priority  sequence  and  is  usually  concerned  with  a  shorter  near-term  horizon  (two  to 
eight  weeks).  Note  also  that  STL  is  more  accurate  than  LTL  within  this  horizon  because  it 
deals  with  specific  machine  capacity  rather  than  a  more  general  aggregate  of  “machine  type 
family”  capacity  utilized  by  LTL.  Other  differences  between  short-term  and  long-term  loading 
are  highlighted  in  Figure  3-34.  Data  flow  diagrams  highlighting  major  activities  of  STL  are  il¬ 
lustrated  in  Figure  3-33.  Activities  1  through  4  are  similar  to  those  carried  out  by  LTL  in 
Figure  3  31.  Activities  5  through  7,  however,  involve  the  selection  of  specific  machines,  a 
determination  of  specific  days  on  which  operations  are  to  be  performed,  and  the  necessary  da¬ 
tabase  updates. 

5.  Short-iron  Balancing  (STB) 

The  primary  objective  of  STB  is  to  balance  overloads  detected  as  a  result  of  short-term 
loading.  Major  differences  between  STB  and  LTB  are  summarized  in  Figure  3-35. 

6.  Define  Factory  Capacity 

Before  any  of  the  long-term  or  short-term  capacity  planning  transactions  are  executed,  it  is 
first  necessary  to  specify  the  capacity  of  the  individual  machines  within  the  manufacturing  en¬ 
vironment  This  transaction  enables  the  capacity  planner  to  interactively  define  capacity  for 
one  or  more  machines.  The  design  of  this  transaction  enables  the  definition  of  capacity  by 
production  control  personnel  at  any  level  in  the  factory  organization  for  various  planning  hor¬ 
izons.  For  example: 

•  A  planner  interested  in  projecting  long-range  load  versus  capacity  may  use  this  transac¬ 
tion  to  define  SINGLE  SHIFT  capacity  for  ALL  machines  in  the  factory  for  the  next 
two  years.  OR 

•  A  planner  interested  in  solving  medium-range  capacity  problems  may  use  this  transac¬ 
tion  to  increase  capacity  for  certain  bottleneck  work  centers  (e.g.,  “DEPT5  DRILLS”) 
for  the  next  few  months.  OR 

•  A  shop  foreman  may  use  this  transaction  to  define  overtime  capacity  for  the  upcoming 
weekend  for  a  specific  machine  (e.g.,  “DRILL25”). 


7.  Display  Capacity 

This  transaction  was  designed  for  the  purpose  of  enabling  a  capacity  planner  to  graphically 
display  the  summarized  capacity  (as  defined  via  the  previous  transaction)  for  a  specific 
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resource  or  resource  machine  type  combination  ((e.g.,  “CENTER1  DRILLS”)  within  the  fac¬ 
tory  hierarchy.  A  sample  bar  chart  display  resulting  from  the  execution  of  this  transaction  is 
included  in  Figure  3*36  (Bar  Chart  for  Displaying  Capacity). 

8.  Dispiay  Load  Versus  Capacity 

This  transaction  enables  a  capacity  planner  to  graphically  display  the  results  of  LTL  or 
LTB.  Its  design  provides  for  the  display  of  load  versus  capacity  for  a  specific  resource  or 
resource  machine  type  combination  defined  within  the  factory  hierarchy.  The  load  versus  ca¬ 
pacity  dispiay  may  be  specified  for  weeks,  months,  or  quarterly  periods.  A  sample  bar  chart 
display  resulting  from  the  execution  of  this  transaction  is  included  in  Figure  3-37  (Bar  Chart 
Dispiay  for  Load  vs.  Capacity). 

9.  Display  Detailed  Capacity  Versus  Load  Profile 

This  transaction  enables  a  capacity  planner  to  graphically  display  the  results  of  STL  or  STB. 
Its  design  provides  for  the  dispiay  of  load  versus  capacity  for  a  specific  machine  or  process 
defined  within  the  factory  hierarchy.  Load  versus  capacity  is  displayed  in  terms  of  days. 

10.  Display  Load/Bal&ndng  Results 

This  transaction  provides  the  user  with  a  hard-copy  report  detailing  the  load  for  a  specified 
range  of  planning  periods.  This  report  can  be  generated  after  the  execution  of  LTL  or  LTB 
and  summarizes  load  in  terms  of  order  numbers,  part  numbers,  specific  operations  compris¬ 
ing  the  load,  and  effective  load  hours  (i.e.,  run  time  and  setup  time). 


Figure  3-36.  Bar  Chart  for  Displaying  Capacity 
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11.  Display  Detail  Load  Schedule 

This  transaction  provides  the  user  with  a  hard-copy  report  detailing  schedule  information 
generated  from  the  execution  of  STB.  This  report  differs  from  that  of  the  previously  de¬ 
scribed  LTL/LTB  report  in  that  the  priority  information  along  with  the  specific  days  on  which 
jobs  are  to  be  worked  is  included. 

12.  Extract  Data  for  Sit  <jlation 

A  data  extraction  transaction  was  also  developed  to  provide  an  interface  between  PP&CS 
and  scheduling  simulation  software  developed  by  Pritsker  &  Associates  under  Project  Priority 
8205  (IDSS  Build  1).  This  simuladon  software  provides  decision  support  to  the  users  of 
PP&CS  Factory  Loading  software  regarding  short-term  loading  and  short-term  balancing  pa¬ 
rameters  and  the  feasibility  and  risk  of  the  schedules  resulting  from  STB. 

The  primary  tasks  of  the  simulation  are  to  1)  Independently  verify  the  schedule  that 
results  from  PP&CS  STL  and  STB  functions  and  to  2)  Provide  feedback  about  queue  time  pa¬ 
rameters  used  in  the  process.  The  secondary  but  still  important  tasks  are  to  provide  feedback 
abrut  PP&CS  move  time  and  slack  time  parameters  and  to  provide  information  on  resource 
utilization. 

The  first  step  in  the  simulation  is  to  extract  from  the  PP&CS  data  base  schedule  informa- 
don  generated  by  STB.  The  extraction  is  performed  by  the  EXTRACT  DATA.  FOR  SIMU¬ 
LATION  transaction.  Using  planned  move  times  and  effective  load  hours,  the  simulation 


Figure  3-37.  Bar  Chart  Display  for  Load  vs  Capacity 
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then  proceeds  to  build  queues  of  work  load  based  on  the  assumption  that  a  job  is  ready  to  be 
moved  and  queued  for  the  next  operation  when  complete  on  the  current  operation.  Simulat¬ 
ed  queue  times  are  thereby  determined  that  can  then  be  used  in  adjusting  queue  time  as¬ 
sumptions  for  short-term  loading  and  balancing. 

The  simulation  also  indicates  underutilized  machines  and  bottleneck  machines.  Such  data 
can  then  be  used  by  the  production  planner  to  modify  selected  loading  rules  or  to  make 
recommendations  for  increased  or  decreased  capacity.  A  block  diagram  illustrating  informa¬ 
tion  interfaces  and  primary  software  modules  for  the  simulation  is  included  in  Figure  3-38. 

The  simulation  is  performed  by  software  referred  to  as  the  Schedule  Evaluator  AM  (appli¬ 
cation  model).  Feedback  in  the  form  of  hard-copy  reports  and  interactive  displays  is  provided 
by  software  referred  to  as  the  Heuristic  Parameter  Analysis  AM. 

The  User’s  Manual  that  describes  the  Schedule  Evaluator  and  Heuristic  Parameter  analysis 
is  available  in  the  ICAM  Library  referenced  UM820540031. 

Factory  Loading  Detailed  Design  Techniques 

Several  innovative  techniques  and  concepts  were  incorporated  into  the  detailed  design  of 
PP&CS  Factory  Londing  software  in  support  of  several  of  the  above  functions.  Specific  tech¬ 
niques  include: 

•  Multi-Tasking 

•  Automatic  Restart  in  the  Event  of  Deadlock 

•  Interactive  Restart  in  the  Event  of  System  Failure  (e.g.,  Power  Outage,  Disk  Head 
Crash) 

•  Slack  Time  Sliding 

Each  of  these  techniques  as  incorporated  within  the  design  of  PP&CS  Factory  Loading 
software  is  briefly  described  as  follows: 

13.  Multi-tasking 

Multi-tasking  involves  the  execution  of  multiple  concurrent  tasks  (implemented  as  “de¬ 
tached  processes”  under  the  VAX/VMS  operating  ./stem)  in  an  attempt  to  reduce  the  sub¬ 
stantial  amount  of  turnaround  time  required  by  Factory  Loading  background  functions. 
Depending  on  the  specific  factory  environment  within  which  PP&CS  is  installed,  it  is  possible 
that  several  of  the  previously  described  Factory  Loading  functions  (namely  LTL,  LTB,  STL, 
and  STB)  could  be  called  upon  to  process  large  amounts  of  load  information.  100,000  pro¬ 
duction  requirements  associated  with  800,000  operations  does  not  represent  an  unusual 
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volume  of  information  to  be  processed  for  a  six  month  time  horizon  in  certain  aerospace 
manufacturing  environments.  Multi-tasking  is  a  technique  for  reducing  the  amount  of  time 
required  to  process  large  volumes  of  information. 

Activities  3  and  5  illustrated  in  the  data  flow  diagram  for  LTL  (Figure  3-31)  and  the  1'er- 
form  Attempts  activity  for  the  LTB  data  flow  diagrams  (Figure  3-32)  are  examples  of  activi¬ 
ties  that  can  be  multi-tasked. 

14.  Automatic  Restart  in  the  Event  of  Deadlock 

The  design  of  the  LTL,  LTB  and  STL  Factory  Loading  functions  also  features  the  ability 
to  periodically  store  “checkpoint”  information  which  is  integrated  within  the  PP&CS  data 
base.  These  functions  are  capable  of  detecting  the  event  of  a  deadlock  condition  and,  using 
checkpoint  information,  are  designed  to  automatically  restart  from  the  last  database  “clean- 
point.'’  This  technique  enables  the  function  to  continue  with  minimal  loss  of  processing. 

After  detecting  a  deadlock  condition,  the  PP&CS  software  will  rollback  (i.e.,  undo) 
modifications  and  locks  that  have  been  applied  to  the  FP&CS  data  base  since  the  last  database 
clcanpoint  (thereby  resolving  the  deadlock  condition)  and  will  then  restart  the  function. 

15.  Interactive  Restart  in  the  Event  of  System  Failure 
(e.g.,  Power  Outage,  Disk  Head  Crash) 

In  the  event  of  mtuor  system  catastrophes,  several  Factory  Loading  functions  have  been 
designed  to  be  interactively  restarted  without  the  need  to  perform  substantial  amounts  of 
reprocessing.  Examples  of  circumstances  under  which  it  is  desirable  to  interactively  restart 
Factory  Loading  functions  include  power  failures  and  hardware  failures  such  as  disk  head 
crashes.  In  all  cases,  the  interactive  restart  feature  uses  the  same  checkpoint  information 
used  by  the  previously  described  automatic  restart  feature. 

Note  that  in  the  event  of  the  loss  of  a  secondary  storage  device,  it  may  be  necessary  to 
use  “after  images”  stored  within  a  “journal  file”  maintained  by  the  data  base  management 
system  (VAX  11  DBMS)  to  reconstruct  (i.e.,  rollforward)  the  data  base  before  interactively 
restarting  the  specific  Factory  Loading  functions  that  were  executing  at  the  time  of  the  failure. 

16.  Slack  Time  Sliding 

The  design  of  LTB  and  STB  incorporates  a  novel  technique  referred  to  as  “slack  time  slid¬ 
ing”  used  for  the  purpose  of  moving  planned  work  (i.e.,  “load  units”)  from  overloaded  to 
underloaded  periods.  This  technique  begins  with  the  determination  of  total  slack  time  avail¬ 
able  for  each  production  requirement  eligible  for  either  the  short-term  or  long-term  loading 
process.  Total  slack  time  is  calculated  by  subtracting  the  total  manufacturing  lead  time  (in 
terms  of  move  time,  queue  time,  and  effective  load  hours  for  each  operation  of  a  part  to  be 
produced)  from  the  total  span  time  (due  date  minus  release  date  as  determined  by  MRP). 
The  total  slack  time  is  divided  up  and  allocated  to  each  of  the  operations  within  a  production 
requirement  Operations  are  then  grouped  into  “load  units”  consisting  of  move  time,  queue 
time,  effective  load  hours,  and  slack  time  as  illustrated  in  Figure  3-39. 

Software  modules  for  LTB  and  STB  were  designed  to  take  advantage  of  slack  time  associ¬ 
ated  with  each  load  unit  for  the  purpose  of  moving  a  load  unit  from  its  current  overloaded 
planning  period  to  either  an  earlier  or  later  period.  In  addition,  more  sophisticated  “look 
ahead”  and  “look  back”  algorithms  were  also  developed  to  take  advantage  of  slack  time  allo¬ 
cated  to  one  or  more  load  units  following  or  preceding  the  current  load  unit  under  considera¬ 
tion. 
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To  the  best  of  our  knowledge,  slack  time  sliding  and  the  techniques  of  generic  “look 
ahead”  and  “look  back”  have  never  before  been  attempted  in  commercial  Capacity  Require¬ 
ments  Planning  (CRP)  packages.  More  detailed  information  regarding  slack  time  siiding  tech¬ 
niques  is  presented  in  the  product  specification  for  the  Perform  Factory  Loading  functicn 
(PS  550152061). 

3.5.3. 2  Record  and  Provide  Production  Information  (PS55Q154081) 

Accomplishments 

A  number  of  transactions  were  designed  in  support  of  the  Record  and  Provide  Production 
Information  function  of  PP&CS.  Specifically,  detailed  design  documentation  for  the  following 
transactions  was  developed. 

1.  Define  Factory  Levels 

Before  executing  any  of  the  previously  described  Factory  Loading  functions,  it  is  first 
necessary  to  define  the  factory  environment  or  organization  at  which  PP&CS  is  to  be  in¬ 
stalled.  The  first  step  in  this  process  is  to  define  the  factory  environment  in  terms  of  control 
levels,  a  function  provided  by  the  DEFINE  FACTORY  LEVELS  transaction. 

Specifically,  this  transaction  enables  the  planner  to  define  the  names  of  levels  and  the  total 
number  of  levels  (up  to  a  maximum  of  10)  for  the  manufacturing  environment. 

Figure  3-40  illustrates  the  ICAM  Factory  Hierarchy,  a  five  level  control  structure  com¬ 
posed  of  factory,  center,  cell,  station  and  process  levels.  This  transaction  provides  PP&CS 
with  the  flexibility  required  to  accommodate  the  control  structure  of  virtually  any  factory  en¬ 
vironment. 

2.  Define  Factory  Resource 

After  defining  the  levels,  it  is  necessary  to  define  the  actual  resources  wi*hin  the  factory 
environment.  A  resource,  can  be  either  a  logical  or  physical  resource.  That  is,  specific  ma¬ 
chines  or  processes  are  ph;  sical  resources  and  appear  at  the  lowest  level  in  the  factory  hierar¬ 
chy.  Capacity  planning  also  involves  logical  resources,  e.g.,  groups  of  machines,  work  centers, 
entire  departments,  etc.,  appearing  at  intermediate  and  higher  levels  in  the  factory  hierarchy. 

3.  Delete  Factory  Resource 

This  transaction  enables  the  planner  to  remove  from  the  PP&CS  data  base  previously 
defined  resources. 

4.  Display  Factory  Hierarchy 

This  transaction  enables  the  planner  to  interactively  display,  as  an  indented  list,  the 
defined  factory  hierarchy. 

5.  Define  Machine  Type 

This  transaction  enables  the  planner  to  group  specific  machines  or  processes  into  machine 
types.  Typical  examples  of  machine  types  include  DRILLS,  MILLS,  NC-LATHES, 
6FT-SHEARS,  etc.  This  step  is  required  since  PP&CS  LTL  software  loads  work  to  machine 
types  within  specific  resources  (i.e.,  “resource  machine  types”)  and  because  STL  software  as¬ 
sociates  work  with  specific  machines  within  a  machine  type  called  out  by  the  process  planning 
information  stored  within  the  PP&CS  data  base. 
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Figure  3-40.  The  ICAM  Factory  Hierarchy 


6.  Delete  Machine  Type  information 

This  transaction  enables  the  tanner  to  delete  from  the  PP.4CS  data  base  previously 
defined  machine  type  informatics. 

7.  Define  Move  Time  information 

Backward  and  forward  loading  techniques  employed  within  both  long-term  and  short-term 
loading/ balancing  software  take  into  consideration  the  time  required  to  move  a  job  from  its 
current  machine  tc  the  machine  or  process  at  which  the  next  operation  is  to  be  performed. 
These  planned  move  times  must  be  established  within  the  PP&CS  data  base  and  are  account¬ 
ed  for  during  the  process  of  offsetting  work  from  its  required  date  (backward  loading)  or 
from  its  start  date  (forward  loading).  This  transacMon  enables  the  planner  to  interactively 
define  planned  move  times. 

8.  Maintain  Shop  Calendar  Parameters 

Shop  calendar  information  for  the  target  manufacturing  environment  must  ciso  be  defined 
prior  to  the  invocation  of  long-term  or  short-term  capaciiy  planning  software.  This  transac¬ 
tion  enables  the  planner  to  define  shop  calendar  parameters  that  will  be  used  to  construct  the 
actual  shop  calendar  within  the  PP&CS  data  base. 

Specifically,  this  transaction  enables  the  user  to  define  a  fiscal  week  to  month  breakdown, 
the  beginning  day  of  the  fiscal  week,  an  upper  limit  for  manufacturing  days  (M-days),  and 
shutdown  days  for  which  no  M-days  are  assigned  The  flexibility  provided  by  ihis  transaction 
enables  PP&CS  to  accommodate  shop  calendars  in  use  in  many  manufacturing  environments 
without  the  need  for  special  i«:k>nng  of  the  software 
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9.  Maintain  Shop  Calendar 

After  defining  shop  calendar  parameters  specific  to  the  user’s  factory,  it  is  then  necessary 
to  build  the  actual  calendar  within  the  PP&.CS  data  base,  a  function  provided  by  the  MAIN¬ 
TAIN  SHOP  CALENDAR  transaction.  In  particular,  this  transaction  creates  planning  period 
records  for  calendar  days,  fiscal  weeks,  fiscal  months,  fiscal  quarters,  and  fiscal  years,  and  also 
associates  M-days  to  calendar  days.  Such  information  is  required  by  both  long-term  and 
short-term  capacity  plarnmg  software. 

10.  Display  Shop  Calendar  Intwcition 

This  transaction  entbles  the  planner  to  display  shop  calendar  information  constructed  in 
accordance  with  the  two  previously  described  tra  nsactions.  Figure  3-41  illustrates  the  format 
of  this  display. 

11.  Adjust  Factory  Load  Parameters 

Several  additional  parameters  must  also  be  defined  prior  to  the  execution  of  long-term  or 
short-term  capacity  pisnning  software.  Amon.'t  these  are  queue  times,  validation  limits, 
compression  factors,  effectiveness  rates,  etc.  Tne  ADJUST  FACTORY  LOAD  PARAME¬ 
TERS  transaction  enables  the  user  to  define  such  parameters,  each  of  which  is  described  in 
detail  in  the  product  specification  for  Record  and  Provide  Production  Information  function 
(PS  550152081). 

3.S.3.3  RelfJt  Production  Reqnirtmena  ( PS5501S3Q71 ) 

Accomplishments 

A  number  of  transactions  were  designed  in  suppoit  of  the  Release  Production  Require¬ 
ments  function  of  PPA.CS.  Specifically,  detailed  design  docum  citation  for  the  following  tran¬ 
sactions  was  developed. 

1.  Set  Release  Parameters 

This  function  enables  a  planner  to  set  several  release  parameters  that  must  be  established 
prior  to  the  actual  release  of  work  to  the  shop  floor.  Specific  examples  of  release  rotameters 
include  upper  and  lower  limits  of  released  work  load  for  specific  resources,  in-vork-date 
release  intervals,  and  flags  in  treating  whether  cr  not  work  is  to  be  automatically  released  to 
certain  resources. 

2.  Assign  Production  Requirements 

This  function  is  designed  to  aruept  as  input  the  schedule  of  production  requirements  es¬ 
tablished  by  previously  described  PP&CS  STB  software  and  to  logically  associate  the  schedule 
with  specific  resources  to  which  the  scheduled  work  will  ultimately  be  released. 

3.  Estimate  Release  Dates 

This  function  results  in  a  determination  cf  expected  release  dates  for  production  require¬ 
ments  associated  with  a  resource  as  a  result  of  the  ASSIGN  PRODUCTION  REQUIRE¬ 
MENTS  funcuon. 

4.  Display  Release  Schedule 

This  function  enables  the  user  to  display  the  release  schedule  established  via  the  ESTI¬ 
MATE  RELF.ASE  DATES  transaction.  The  release  schedule  ia  designed  to  be  displayed  ei¬ 
ther  on  the  user's  terminal  or  optionally  as  a  hard-copy  report. 
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Figure  3-41.  Format  for  Displaying  Shop  Calendar  Information 


5.  Identify  Quantity  Adjustments 

This  function  e^nerates  a  report  identifying  qua.  ;ty  adjustments  suggested  for  production 
requirements  to  .eieased  for  resources  selected  by  the  user,  fhis  transaction  was  originally 
included  within  the  PP&CS  design  as  a  utility  for  suggesting  quantity  adjustments  in  the  event 
that  MRP  software  is  not  used  at  the  manufacturing  site  at  which  PP&CS  software  is  installed. 

6.  Adjust  Production  Requirements 

As  a  complement  to  the  IDENTIFY  QUANTITY  ADJUSTMENTS  transaction,  this  func¬ 
tion  enables  the  user  to  interactively  modify  quantities  of  oarts  identified  on  production  re¬ 
quirements  about  to  be  released  to  the  shop  floor. 

7.  Display  Load  Status 

This  function  displays  current  load  information  for  ail  rest  rces  defined  within  the  factory 
hierarchy.  The  display  is  presented  both  graphically  and  as  a  conventional  text  display. 

8.  Select  Resources  for  Release 

This  function  enables  the  user  to  select  the  resources  to  which  production  requirements 
are  to  be  released  and  to  specify  the  amount  of  work  in  hours  to  be  released.  (Illustrated  in 
Figure  3-42) 
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U  =  RELEASED  LOAD  UPPER  LIMIT 
L  s  RELEASED  LOAD  LOWER  LIMIT 
R  =  ALREADY  RELEASED 

I  =  IMPACT,  THE  AMOUNT  OF  WORK  TO  BE  RELEASED 
T  a  TOTAL  AMOUNT  OF  WORK  FROM  DETAIL  SCHEDULE 

Figure  3-42.  Select  Resources  for  Release 


9.  Analyze  Release  Impact 

This  function  analyzes  the  workload  about  to  be  refeased  to  previously  selected  resources 
and  determines  the  impact  of  the  release  on  ail  resources.  If,  for  example,  it  is  determined 
that  1000  hours  of  work  is  to  be  released  to  a  particular  resource,  this  function  provides  the 
user  with  an  understanding  of  how  that  1000  hours  will  be  distributed  among  lower-level 
resources.  It  is  therefore  possible  to  gain  an  understanding  of  potential  short-term 
bottlenecks  cr  underloaded  situations.  The  need  for  overtime,  reassignment,  farmout,  or  ex¬ 
pediting  can  therefore  be  more  accurately  predicted.  Note  that  the  output  of  this  function  is 
displayed  via  the  invocation  of  the  previously  described  DISPLAY  LOAD  STATUS  function. 

10.  Release  Production  R equipments  for  Interactively  Selected  Resources 

This  function  enables  the  usu  to  release  production  requirements  to  resources  defined 
within  the  factory  hierarchy.  Sperhc  resources  to  which  production  requirements  are  to  be 
released  are  selected  via  the  SELECT  RESOURCES  FOR  RELEASE  function. 
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11.  Start  Automatic  Release 

This  function  enables  the  user  to  initiate  the  automatic  release  of  work  to  resources  that 
were  previously  identified  as  eligible  for  autoir^oc  release.  Eligibility  for  autocade  release  is 
granted  to  a  resource  as  a  result  of  executing,  the  RELEASE  PARAMETERS  function. 

12.  Stop  Automatic  Release 

This  function  enables  the  user  to  terminate  the  automatic  release  of  work  to  resources 
that  were  previously  identified  as  eligible  for  automatic  release.  The  automatic  release  mecha¬ 
nism  is  ac'ivated  via  the  START  AUTOMATIC  RELEASE  function. 

3.S.3.4  Perform  Resultant  Processing  (PS55015209I) 

Accomplishments 

Detailed  design  documentation  for  three  maior  resultant  processing  functions  was  com¬ 
pleted  during  this  phase  of  the  project.  These  functions  are: 

1.  Validity  Check  Feedback  Information 

This  function  is  responsible  for  validating  production  information  collected  from  the  shop 
floor.  Specifically,  validation  consists  of: 

•  Checking  actual  performance  information  (e.g.,  actual  run  time,  actual  setup  time,  scrap 
counts,  etc.)  for  identifying  substantial  deviations  from  standauts 

•  Detection  of  missing  values 

This  function  is  designed  to  accept  as  input  performance  information  stored  within  the 
PP&CS  data  base  by  an  appropriate  shop  floor  control  system.  The  output  of  this  function  is 
a  report,  illustrated  in  Figure  ?-4J,  that  identifies  the  deviations  and  missing  values. 

2.  Update  Historical  Performance 

This  function  is  responsible  for  updating  historical  performance  information.  Examples  of 
historical  data  maintained  within  the  PP&CS  data  base  include: 

•  ROUTING  OPERATION  HISTORY 

•  ROUTING  OPERATION  HISTORICAL  SAMPLES 

•  MOVE  TIME  HISTORY 

•  MOVE  TIME  SAMPLES 

•  RESOURCE  MACHiNE  TYPE  HISTORY 

•  PART  HISTORY 

•  PART  HISTORf  SAMPLES 

This  function  maintains  parameters  indicating  the  maximum  number  c  '  samples  that  can 
be  stored  for  each  category  of  historical  information,  thereby  enabling  the  manufacturing  site 
to  manage  the  growth  and  proliferation  of  historical  information  within  the  PP&CS  data  base. 
The  oldest  samples  are  deleted  from  the  data  base  when  upper  limits  are  reached. 

Note  that  the  VALIDITY  CHECK  FEEDBACK  INFORMATION  and  UPDATE  HISTOR¬ 
ICAL  PERFORMANCE  functions  were  integrated  within  the  design  of  a  single  transaction. 
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Figare  3*43.  Validity  Check  Results 


3.  Analyte  Performance 

This  function  is  primarily  -esponsible  for  retrieving  historical  performance  samples  for  any 
of  several  variables  stored  within  the  PP&CS  data  base  (after  validation  has  been  performed) 
and  plotting  associated  scatter  diagrams  and  trend  lines.  This  function  thereby  enables  the 
planner  to  determine  whether  significant  trends  are  developing  (e.g.,  determining  whether  or 
not  learning  curves  are  being  overcome  for  new  processes). 

Specific  types  of  data  analyzed  by  this  function  include: 

•  Move  Time  Deviation 

•  Queue  Time  Deviation 

•  Setup  Time  Deviation 

•  Setup  Loss  Deviation 

•  Delivery  Variance 

•  Slack  Time 

•  Quantity  Variance 
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*  Operating  Time  Deviation 

•  Total  Span  Time 

A  sample  display  generated  from  this  function  is  illustrated  in  Figure  3-44. 

3.6  TASK  6.  SUBTASK  1:  DEVELOP  “CONSTRUCT,  INTEGRATE  AND  TEST”  SUB¬ 
PLAN 

3.6.1  Construct,  Integrate,  and  Test  Plan 
Accomplishments 

A  provision  for  a  test  plan  that  included  training,  coding,  testing,  verification,  and  systems 
test  was  developed  in  Task  5.  Subtask  3.  In  this  task,  the  plan  was  reviewed  for  completeness 
and  communicated  to  the  software  engineering  team. 

At  this  time  the  plan  was  finalized  for  the  implementation  and  demonstration  of  the 
PP&CS  prototype  system.  The  computer  selected  for  coding,  testing,  and  implementation  was 
the  VAX  11/780  and  the  VAX  1 1  DBMS. 

3.6.2  Task  6,  Subtask  2:  Construct,  Code,  and  Verify  IPS  Subsystem  Prototype 
Accomplishments 

This  phase  of  the  project  resulted  in  the  construction  of  approximately  2000  discrete 
software  modules  addressing  all  of  the  functions  in  Section  3.5.3  for  the  following  PP&CS 
areas: 

1.  Perform  Factory  Loading 

2.  Record  and  Provide  Production  Information 
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Figure  3-44.  Slack  Tine  Deviation 
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3.  Perform  Resultant  Processing 

In  order  to  effectively  carry  out  this  phase  of  the  effort,  it  was  necessary  to  address  a  num¬ 
ber  of  software  implementation  issues  and  problems.  Specific  concerns  encountered  during 
this  phase  are  summarized  as  follows: 

1.  Choice  of  Computer  System 

It  was  originally  contemplated  that  PP&CS  be  demonstrated  as  a  subsystem  executing 
under  the  control  of  the  IISS  test  bed  (ICAM  project  6201).  The  initial  implementation  of 
the  test  bed.  for  which  PP&CS  was  targetted,  demonstrated  data  integration  within  a  distribut¬ 
ed  heterogeneous  computer  network  consisting  cf  VAX  11/780,  Honeywell  Level  6,  and 
IBM  3033  computer  systems.  Clearly,  before  PP&CS  software  could  be  constructed,  it  was 
first  necessary  to  choose  the  test  bed  computer  system  on  which  PP&CS  software  would  be 
implemented  and  demonstrated. 

An  analysis  was  performed  for  the  purpose  of  selecting  the  target  computer,  specifically, 
the  operating  environments,  i.e.,  operating  system,  compilers,  available  data  base  manage¬ 
ment  systems,  screen  formatting/forms  management  software,  etc.  for  each  of  the  three 
above  systems.  Other  non-technical  issues,  such  as  computer  system  popularity  within  the 
aerospace  community,  contract  funding  for  computer  system  usage  (i.e.,  connect  time,  disk 
usage,  epu  usage),  and  available  capacity  were  also  considered  in  the  final  decision  making 
process. 

The  final  recommendation  of  the  PP&CS  development  team  was  to  proceed  with  the  im¬ 
plementation  of  PP&CS  on  the  VAX.  Primary  reasons  in  favor  of  this  choice  included: 

•  Richness  of  the  operating  environment  (vendor  supported  CODASYL-compliant  data 
base  management  and  screen  formatting  software) 

•  Availability  of  development  capacity  on  both  IISS  and  General  Electric-owned  VAX  sys¬ 
tems 

•  VAX  popularity  within  aerospace  industry 

2.  Choice  of  Implementation  Language 

The  language  recommended  for  PP&CS  implementation  was  the  ANSI  ’74  COBOL  stan¬ 
dard.  Primary  reasons  for  this  recommendation  included: 

•  Vendor  support  of  standard  interface  (CODASYL)  for  data  base  management 

•  Compliance  with  initial  IISS  test  bed  standards 

•  Maintainability  and  readability 

•  User  preference  as  evidenced  by  an  overwhelming  number  of  computer-aided  manufac¬ 
turing  systems  implemented  in  COBOL 

3.  Choice  of  Data  Base  Management  System 

Having  selected  the  VAX  as  the  target  implementation  system,  it  was  then  necessary  to 
explore  alternative  approaches  for  implementing  the  PP&CS  data  base.  Three  different  data 
base  management  systems  were  considered: 


•  VAX  11  DBMS 

•  ORACLE 
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•  The  IISS  Neutral  Data  Manipulation  Language  (NDML)  and  Common  Data  Model 

(CDM) 

VAX  11  DBMS  was  selected.  A  primary  reason  for  this  selection  centers  around  the  issue 
of  transportatilhy.  VAX11  DBMS  is  a  CODASYL-compiiant  data  base  management  system. 
The  CODASYl  approach  to  data  base  management  is  well-understood  within  the  computer 
industry  and  is  supported  by  many  computer  vendors  as  a  standard.  Integral  feature  of  the 
COBOL  compiler.  ANSI  ’74  COBOL  coupled  with  a  CODASYL-compiiant  DBMS  provides  a 
relatively  strong  degree  of  transportability  and  enhances  the  probability  of  successful  PP&CS 
radiation  within  the  aerospace  industry. 

ORACLE,  on  the  other  hand,  represents  a  newer  technology  in  data  base  management 
(i.e.,  the  relational  approach).  To  the  best  knowlege  of  the  PP&CS  development  team,  no 
ORACLE  customer  had  previously  applied  ORACLE  to  the  problem  of  managing  large 
volumes  of  tightly  interrelated  data  for  a  software  application  as  complicated  as  manufacturing 
capacity  planning.  The  performance  capabilities  of  ORACLE  for  the  PP&CS  application  there¬ 
fore  could  not  be  verified  without  extensive  testing  and  prototyping. 

The  primary  reason  for  not  recommending  the  IISS  NDML  was  the  fact  that  its  initial  im¬ 
plementation  within  the  IISS  test  bed  was  planned  to  support  a  “read  only”  capability.  A  lo¬ 
cal  update  capability  for  the  NDML/CDM  combination,  which  would  have  been  required  for 
PP&CS  implementation,  was  targetted  for  a  test  bed  software  release  scheduled  beyond 
PP&CS  schedule  requirements. 

4.  Choice  of  Forms  Management  Software 

Having  selected  the  VAX  as  the  target  implementation  system,  it  was  also  necessary  to  ex¬ 
plore  alternative  screen  formatting  packages  for  implementing  the  PP&CS  user  interface. 
Two  screen  formatting  packages  were  considered: 

•  FMS  (Form  Management  System),  a  DEC  standard  product,  and 

•  The  IISS  User  Interface  (UI),  screen  formatting  and  virtual  terminal  interface  software 
developed  under  the  6201 M  effort. 

FMS  was  selected  primarily  for  the  following  reasons: 

The  timing  of  the  development  releases  for  IISS  software  did  not  coincide  with  the 
scheduled  needs  of  the  construct,  integrate  and  test  of  PP&CS. 

•  FMS  Reliability:  FMS  is  vendor-supported.  It  exists,  has  been  proven  to  be  reliable,  and 
is  well-accepted  in  user  communities. 

•  Schedule  Imbalance:  The  product  calendar  for  IISS  User  Interface  was  not  in  synchrony 
with  PP&CS  schedule  requirements.  PP&CS  implementation  commenced  prior  to  com¬ 
pletion  of  the  initial  release  of  the  T>st  Bed  UI. 

5.  Transaction  Processing 

The  issue  of  whether  or  not  to  use  a  transaction  processor  to  cortrol  the  invocation  and 
execution  of  PP&CS  application  programs  was  also  addressed  during  this  phase.  It  was  decid¬ 
ed  that  the  PP&CS  implementation  did  not  require  use  of  a  transaction  processor. 

The  principal  reasoning  underlying  this  conclusion  was  that  most  critical  PP&CS  applica¬ 
tion  programs  are  designed  to  be  invoked  interactively  by  a  PP&CS  user  but  will  then  execute 
in  “background  mode”  for  a  duration  of  perhaps  several  hou-s.  LTL,  LTB,  and  STL  are  ex¬ 
amples  of  this  mode  of  execution. 
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Transaction  processors,  however,  have  traditionary  been  used  for  applications  where  many 
users  need  to  execute  simple  application  programs  requiring  fast  response  time,  unusual 
amounts  of  terminal  I/O  and/or  data  base  I/O,  (e.g.,  airline  reservations,  banking,  shop  floor 
control,  etc.).  For  such  applications,  a  transaction  processor  is  sometimes  use J,  serving  as  a 
message  manager  for  optimizing  and  controlling  terminal  I/O. 

Access  to  PP&CS  functions,  on  the  other  hand,  will  normally  be  restricted  to  only  a  few 
factory  personnel  (e.g.,  a  factory  load  planner  and  a  person  responsible  for  to  the  shop 

floor).  Fast  response  for  important  PP&CS  applications  is  neither  required  nor  possible  with 
contemporary  computer  technology.  Very  little  terminal  I/O  is  also  required  by  PP&CS  appli¬ 
cation  programs.  Use  of  a  transaction  processor  for  PP&CS  was  therefore  not  regarded  as 
essential. 

6.  Considerations  When  Executing  “Background”  Jobs 

As  previously  described,  several  PP&CS  factory  loading  functions  run  as  background  jobs 
capable  of  being  executed  in  a  “multi-tasked”  mode  of  operation.  As  a  result  of  this  ap¬ 
proach,  several  related  technical  issues  needed  to  be  addressed  during  this  phase  of  the  proj¬ 
ect-  Among  them  were  the  determination  of  VAX/VMS  mechanisms  for 

•  Controlling  the  creation  and  execution  of  background  jobs 

•  Sending  completion/error  messages  from  a  background  job  to  the  initiating  user 

•  Controlling  user  access  to  currently  executing  background  jobs. 

Solutions  for  each  of  these  issues  were  devised  and  are  appropriately  documented  in  the 
as-built  product  specification  for  Factory  Loading. 

In  addition  to  the  above  issues,  a  number  of  more  detailed  implementation  issues  were 
also  addressed  during  this  phase  of  the  effort.  Discussion  of  these  issues  is  included  in  ap¬ 
propriate  product  specifications  referenced  in  paragraph  3.5.3.  . . . 

3.6.3  Task  6,  Scbtask  3:  Integrate,  Test,  and  Validate  IPS  Subsystem  Prototype 

Accomplishments 

This  phase  of  the  project  resulted  in  the  unit  testing  and  integration  testing  for  the  follow¬ 
ing  PP&CS  functional  areas: 

1.  Perform  Factory  Loading 

2.  ,  cord  and  Provide  Production  Information 

3.  Perform  Resultant  Processing 

Several  roteworthy  techniques,  described  as  follows,  were  employed  to  more  effectively 
carry  out  the  software  testing  process: 

1.  Antibugging 

A  technique  referred  to  as  “antibugging”  was  incorporated  within  all  source  codes  con¬ 
structed  for  PP&CS  application  software.  Yourdon,  in  his  text  “Techniques  of  Program 
Structure  and  Design”  (Prentice-Hail  1975),  defines  antibugging  as  “the  philosophy  of  writing 
programs  in  such  a  way  as  to  make  bugs  less  likely  to  occur,  and  when  they  do  occur  (which 
is  inevitable),  to  make  them  more  nodceable  to  the  programmer  and  the  user.” 
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Accordingly,  designers  of  each  transaction  were  commissioned  with  the  responsibility  of 
ensuring  that  all  PP&CS  application  software  be  suitably  equipped  with  appropriate  mecha¬ 
nisms  for  detecting  exception  conditions.  All  software  was  designed  such  that  the  detection 
of  an  exception  condition  is  then  followed  by  the  display  of  an  appropriate  message  indicating 
not  only  the  nature  of  the  exception  condition  but  also  the  name  of  the  software  module  exe¬ 
cuting  at  ihe  time  the  exception  condition  was  detected,  and  the  circumstances  under  which 
the  exception  condition  was  generated. 

2.  Testing  by  Software  Inspection 

Software  inspection  procedures  were  also  established  to  identify  logic  errors  and  violations 
of  design/coding  standards  prior  to  the  actual  execution  of  individual  transactions. 
Specifically,  implementors  were  instructed  to  expend  some  “startup”  time  for  reviewing  de¬ 
tailed  design  documentation  for  the  assigned  transaction.  Points  of  confusion,  change  propos¬ 
als  arising  from  constraints  associated  with  the  target  operating  environment,  and  an  overall 
implementation  approach  were  then  mutually  formulated  by  the  chief  programmer  and  the 
implementor. 

After  the  resolution  of  any  startup  problems,  the  implementor  then  proceeded  to  interac¬ 
tively  create  screen  formats  and  source  modules.  This  step  was  then  followed  by  compilation, 
which  repeated  until  all  syntactic  problems  were  eliminated. 

Cleanly  compiled  source  modules  were  then  submitted  for  inspection  to  the  detailed 
designer,  who  was  then  responsible  for  ensuring  that  algorithms  were  accurately  interpreted 
by  the  coder  and  that  standards  had  been  adhered  to.  This  inspection  process  resulted  in  the 
identification  and  interception  of  a  substantial  number  of  errors,  thereby  reducing  the  amount 
of  time  that  otherwise  might  have  been  expended  for  formal  testing  and  debugging. 

3.  Transaction  Testing 

Satisfactory  completion  of  the  inspection  step  was  then  followed  by  both  unit  testing  and 
transaction  testing  usually  performed  by  the  detailed  designer.  For  straightforward  transac¬ 
tions,  test  cases  were  informally  identified  and  executed.  Antibugging  techniques,  as  previ¬ 
ously  described,  were  heavily  relied  upon  for  identification  of  software  problems.  For  some 
transactions,  test  specifications  identifying  specific  test  cases,  descriptions  of  tests,  and  test 
data  were  developed. 

4.  Integration  Testing 

Integration  testing  demonstrating  proper  coordination  and  interfacing  among  sequences  of 
transactions  was  usually  performed  subsequent  to  the  satisfactory  completion  of  unit  testing 
and  transaction  testing  for  each  transaction  included  within  the  scope  of  a  specific  integration 
test.  In  some  cases,  however,  it  was  necessary  to  perform  integration  tests  in  conjunction 
with  unit  testing  and  transaction  testing. 

Specifically,  integration  testing  was  performed  according  to  the  following  steps: 

1.  Integration  of  STB  with  prototype  configuration  software: 

STB  was  the  first  major  PP&CS  function  developed.  STB  served  as  a  vehicle  for 
demonstrating  PP&CS  progress  at  the  ICAM  Industry  Days  conference  in  New  Or¬ 
leans  in  June  1983.  This  software  was  integrated  with  prototype  software  for  initializ¬ 
ing  the  data  base  with  production  requirements  and  miscellaneous  information  for 
defining  the  factory  environment  and  factory  loading  parameters. 
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2.  Integration  of  Record  and  Provide  transactions: 

Integration  testing  was  then  carried  out  for  transactions  identified  within  the 
Record  and  Provide  Production  Information  function. 

3.  Integration  of  PREPARE  MRP  INPUT  transaction  with  Record  and  Provide  transactions: 

Integration  of  the  PREPARE  MRP  INPUT  transaction  with  record  and  provide 
transactions  actually  commenced  prior  to  completion  of  unit  testing  for  the  PREPARE 
MRP  INPUT  transaction.  This  was  necessary  because  of  the  need  to  appropriately  ini¬ 
tialize  the  PP&CS  data  base  via  execution  cf  Record  and  Provide  transactions  support¬ 
ing  the  Factory  Loading  function. 

4.  Integration  of  LTL  with  the  DEFINE  CAPACITY  AND  PREPARE  MRP  INPUT  transac¬ 
tions: 

This  integration  step  was  performed  in  conjunction  with  LTU  unit  testing. 

5.  Integration  of  LTL  with  L  TB 

6.  Integration  of  LTL  with  STB 

7.  Integration  of  STL  with  STB 

8.  Integration  of  LTULTB  with  Transactions  for  Results  Presentation 

9.  Integration  of  STIJSTB  with  Transactions  for  Results  Presentation 

10.  Integration  of  Resultant  Processing  Transactions 

3.6.4  Task  6,  Subtask  4:  Implement  and  Maintain  IPS  Subsystem  Prototype 

This  phase  of  the  project  resulted  in  the  development  of  user  instruction  information, 
software/data  base  maintenance  information,  operating  procedures,  and  installation  pro¬ 
cedures  for  the  following  PP&CS  functional  areas: 

1.  Perform  Factory  Loading 

2.  Record  and  Provide  Production  Information 

3.  Perform  Resultant  Processing 

A  PP&CS  user’s  manual  (UM  550150300)  was  developed  that  includes  the  following  in¬ 
formation: 

1.  General  Operating  Procedures 

2.  Transaction  Descriptions 

3.  User  Instructions  for  Transaction  Execution 

4.  Sample  Screen  Formats  for  Each  Transaction 

5.  PP&CS  Software  Installation  Procedures 

PP&CS  data  base  maintenance  information  was  incorporated  within  a  data  base 
specification  (DBS  550150000)  developed  in  accordance  with  ICAM  documentation  standards. 

Software  maintenance  information  including  structure  trees  (i.e.,  indented  module  lists), 
module  descriptions,  file  descriptions,  table  descriptions,  etc.,  for  all  PP&CS  transactions  was 
developed  and  incorporated  within  product  specifications  ?lso  developed  in  accordance  with 
ICAM  documentation  standards. 
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PP&CS  software  was  not  installed  at  a  specific  manufacturing  site  as  a  result  of  this  effort. 
The  results  of  the  PP&CS  effort  were  demonstrated  to  industry  representatives  at  an  end-of- 
contract  review  meeting  for  Project  Priority  5501. 

3.7  TASK  7:  PROJECT  MANAGEMENT  AND  DATA 

Accomplishment 

This  task  provided  the  project  management  and  data  for  overall  program  control.  This  ac¬ 
tivity  consisted  of  project  monitoring  and  reporting  of  General  Electric  performance  in  com¬ 
pliance  with  the  Air  Force  contract  requirements. 

The  monitoring  of  IPS  subcontractor  compliance  with  contract  requirements  was  also  ac¬ 
complished  in  this  task.  The  General  Electric  project  manager  provided  project  progress  and 
results,  as  well  as  the  required  ICAM  documentation  and  contract  deliverables,  to  the  Air 
Force,  external  contractors,  and  the  public. 
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The  following  reference  rm.erial  is  available  in  .ire  ^AM  library  ®di«  pm taenttt  *o 
IPS  project.  A  synopsis  and  overview  of  IPS  tecnnical  work  accomplish  d  g  - 

of  Project  Priority  5501  is  contained  in  Section  2  of  this  final  report. 


4.1  PREVIOUS  INTERIM  REPORTS 

Document  Number 


Date 


: 

l 


4.2 


SED  550150000 
SRD  550150000 
SAD  550 1 50000 
SAR  550150000 
SS  550150000 
SDS  550150000 
DS  550152061 

DS  550153071 

DS  550 1 5408 1 


DS  550152091 

DS  5501561 1 1 

TP  550150001 
QAP  550150001 


MIS-81-016 
ITR  550150002U 
ITR  5501 50003  U 
ITR  550150004U 
ITR  550150005U 
ITR  550150006U 
ITR  550150007U 
ITR  550150008U 
ITR  550150009U 
ITR  55C150010U 
ITR  550150011U 
ITR  550150012U 
ITR  550150013U 


31  December  1980 
31  March  1981 
30  June  1981 

30  September  1981 

31  October  1981 
31  March  1982 
30  June  1982 

30  September  1982 

31  December  1982 
31  Marcn  1983 

30  June  1983 

30  September  1983 

31  December  1983 


_ Date _ 

15  January  1981 
3  March  1981 

9  November  1981 
9  November  1981 
9  November  1981 

16  October  1981 
30  June  1982 

9  September  1 982 

17  December  1982 
15  December  1982 


17  December  1982 

15  December  1982 

15  December  1982 
15  December  1982 
3  February  1983 


LIFE  CYCLE  DOCUMENTS 

Document  Number  _ _ Description  _ . 

Scope  Kit 

Needs  Analysis  Document 
System  Environment  Document 
System  Requirement  Docum  int 
State-of-the-art  Document 
State-of-the-art  Review 
System  Specification 
System  Design  Specification 
Development  Specification 

-  Perform  Factory  Loading 
Development  Specification 

-  Release  Production  Requirements 
Development  Specification 

-  Record  &  Provide  Production 
Information 

Development  Specification 

-  Perform  Resultant  Processing 
Development  Specification 

-  PP&CS  Interface 
Test  Plan 

Quality  Assurance  Plan 
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Document  Number 


Description 


Dice 


DBS  550150000 
PS  550152061 

PS  550153071 

PS  550154081 

PS  550152091 
UM  550150000 


Data  Base  Specification  1  May  1984 

Product  Specification 

-  Perform  Factory  Loading  1  May  1984 

Product  Specification 

-  Release  Production  Requirements  1  May  1984 
Product  Specification 

-  Record  &  Provide  Production 

Information  1  May  1984 

Product. Specification 

-  Perform  Resultant  Processing  1  May  1984 

Users  Manual  1  May  1984 


4J  VENDOR-SUPPLIED  DOCUMENTATION 

A  detailed  understanding  of  the  vendor-supplied  support  software,  upon  which  PP&CS 
was  built,  can  be  obtained  from  the  following  manuals  available  from  Digital  Equipment  Cor¬ 
poration: 

DEC  Publication  Number  Manual  Title 


AA-C985A-TE 

AA-C986A-TE 

AA-L629A-TE 

AA-L630A-TE 
and  AD-L360A-T1 
AA-J966A-TE 

AA-J961A-TE 

AA-J960A-TE 

AA-J964A-TE 

AA-J962A-TE 

AA-J965A-TE 

AA-J260A-TE 


VAX-1 1  Cobol-74  Language  Reference  Manual 
VAX-11  Cobol-74  Users  Guide 
VAX-11  Common  Data  Dictionary  Utilities 
Manual 

VAX-11  Common  Data  Dictionary  Installation 
Guide 

VAX- 11  DBMS  Data  Base  Administration 
Manual 

VAX-ll  DBMS  DDL  Reference  Manual 
VAX-11  DBMS  DML  User’s  Guide 
VAX-11  DBMS  Summary  Description 
VAX-11  DBMS  Utilities  Reference  Manual 
VAX-11  DBMS  Installation  Guide  and 
Release  Notes 

VAX- 11  FMS  Software  Reference  Manual 
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